AUTHENTICATED 
US. GOVERNMENT 
INFORMATION ^ 


EXAMINING THE CFTC’S PROPOSED RULE: 
REGULATION AUTOMATED TRADING 


HEARING 

BEFORE THE 

COMMITTEE ON AGRICULTURE 
HOUSE OF REPRESENTATRH]S 

ONE HUNDRED FOURTEENTH CONGRESS 

SECOND SESSION 

JULY 13, 2016 

Serial No. 114-56 



Printed for the use of the Committee on Agriculture 
agriculture.house.gov 


U.S. GOVERNMENT PUBLISHING OFFICE 
20-912 PDF WASHINGTON : 2016 


For sale by the Superintendent of Documents, U.S. Government Publishing Office 
Internet: hookstore.gpo.gov Phone: toll free (866) 512-1800; DC area (202) 512-1800 
Fax: (202) 512-2104 Mail: Stop IDCC, Washington, DC 20402-0001 


COMMITTEE ON AGRICULTURE 

K. MICHAEL CONAWAY, Texas, Chairman 


RANDY NEUGEBAUER, Texas, 

Vice Chairman 
BOB GOODLATTE, Virginia 
FRANK D. LUCAS, Oklahoma 
STEVE KING, Iowa 
MIKE ROGERS, Alabama 
GLENN THOMPSON, Pennsylvania 
BOB GIBBS, Ohio 
AUSTIN SCOTT, Georgia 
ERIC A. “RICK” CRAWFORD, Arkansas 
SCOTT DesJARLAIS, Tennessee 
CHRISTOPHER P. GIBSON, New York 
VICKY HARTZLER, Missouri 
DAN BENISHEK, Michigan 
JEFF DENHAM, California 
DOUG LaMALFA, California 
RODNEY DAVIS, Illinois 
TED S. YOHO, Florida 
JACKIE WALORSKI, Indiana 
RICK W. ALLEN, Georgia 
MIKE BOST, Illinois 
DAVID ROUZER, North Carolina 
RALPH LEE ABRAHAM, Louisiana 
JOHN R. MOOLENAAR, Michigan 
DAN NEWHOUSE, Washington 
TRENT KELLY, Mississippi 


COLLIN C. PETERSON, Minnesota, Ranking 
Minority Member 
DAVID SCOTT, Georgia 
JIM COSTA, California 
TIMOTHY J. WALZ, Minnesota 
MARCIA L. FUDGE, Ohio 
JAMES P. McGovern, Massachusetts 
SUZAN K. DelBENE, Washington 
FILEMON vela, Texas 
MICHELLE LUJAN GRISHAM, New Mexico 
ANN M. KUSTER, New Hampshire 
RICHARD M. NOLAN, Minnesota 
CHERI BUSTOS, Illinois 
SEAN PATRICK MALONEY, New York 
ANN KIRKPATRICK, Arizona 
PETE AGUILAR, California 
STACEY E. PLASKETT, Virgin Islands 
ALMA S. ADAMS, North Carolina 
GWEN GRAHAM, Florida 
BRAD ASHFORD, Nebraska 


Scott C. Graves, Staff Director 
Robert L. Larew, Minority Staff Director 


(II) 



CONTENTS 


Page 

Conaway, Hon. K. Michael, a Representative in Congress from Texas, opening 

statement 1 

Prepared statement 3 

Peterson, Hon. Collin C., a Representative in Congress from Minnesota, open- 
ing statement 4 

Witnesses 

Wood, Gregory John, Chairman, Market Access Committee, Futures Industry 
Association; Director, Electronic and Algorithmic Execution, Listed Deriva- 
tives, Deutsche Bank Securities Inc., Washington, D.C 4 

Prepared statement 6 

Gorelick, J.D., Richard, Chief Executive Officer, RGM Advisors, LLC, Austin, 

TX 11 

Prepared statement 13 

Vrabel, J.D., Andrew, Executive Director, Global Head of Investigations, Mar- 
ket Regulation Department, CME Group, Inc., Chicago, IL 20 

Prepared statement 22 

Ryan, Michael G., Executive Vice President and General Counsel, Trading 

Technologies International, Inc., Chicago, IL 25 

Prepared statement 26 

Submitted Material 

Bergles, Susan, Assistant General Counsel, American Gas Association, sub- 
mitted statement 65 


(III) 




EXAMINING THE CFTC’S PROPOSED RULE: 
REGULATION AUTOMATED TRADING 


WEDNESDAY, JULY 13, 2016 

House of Representatives, 
Committee on Agriculture, 

Washington, D.C. 

The Committee met, pursuant to call, at 10:00 a.m., in Room 
1300 of the Longworth House Office Building, Hon. K. Michael 
Conaway [Chairman of the Committee] presiding. 

Members present: Representatives Conaway, Neugebauer, Good- 
latte, Lucas, King, Thompson, Gibbs, Austin Scott of Georgia, 
Crawford, DesJarlais, Benishek, Denham, LaMalfa, Davis, Allen, 
Moolenaar, Newhouse, Kelly, Peterson, David Scott of Georgia, 
Walz, Fudge, McGovern, DelBene, Vela, Lujan Grisham, Kuster, 
Nolan, Bustos, Kirkpatrick, Aguilar, Plaskett, Adams, and Graham. 

Staff present: Caleb Crosswhite, Darryl Blakey, Haley Graves, 
Kevin Webb, Paul Balzano, Scott C. Graves, Stephanie Addison, 
Liz Friedlander, Matthew MacKenzie, Nicole Scott, and Carly 
Reedholm. 

OPENING STATEMENT OF HON. K. MICHAEL CONAWAY, A 
REPRESENTATIVE IN CONGRESS FROM TEXAS 

The Chairman. Good morning. This hearing of the Committee on 
Agriculture entitled. Examining the CFTC’s Proposed Rule: Regula- 
tion Automated Trading, will come to order. 

I have asked Rick Crawford to open us with a quick prayer. Rick. 

Mr. Crawford. Thank you, Mr. Chairman. 

Heavenly Father, we bow humbly before you today, thankful for 
every blessing of life. Father, thank that we live in this nation that 
you have provided for us. Father, just ask that everything we say 
and do here today be pleasing in your sight. Ask it in Jesus’ name. 
Amen. 

The Chairman. Thank you. 

Good morning, and welcome again to the hearing on Regulation 
Automated Trading. Before we get started, I want to thank both 
Chairman and Ranking Member Scotts. I am not sure how to prop- 
erly phrase that, David, but you and Austin, and all the Members 
of the CEEC Subcommittee for their work over the past few 
months examining Title VII, and working through the ongoing 
challenges in our derivatives markets. Implementing Title VII has 
been a monumental task for regulators. The staff and Commis- 
sioners of the CFTC deserve credit for their work. Much has been 
improved over the past 2 years, but clearly, there remains a signifi- 
cant amount of work to be done, especially in harmonizing rules 
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across borders and fixing outstanding issues like the swap dealer 
de minimis problem. 

Over the past 3 decades, our financial markets have been quietly 
revolutionized by computers. Sometimes called the 
“electronification” of markets, computer networks have slowly re- 
placed the traditional trading pits. Electronic markets allow com- 
puters to seamlessly input orders, giving rise to trading directed 
and conducted entirely by computer algorithms. 

Electronic markets and algorithms offer easier access, reduced 
transaction costs, and support sophisticated tools that even the 
smallest market participants can use. Today, algorithmic trading is 
essential to our futures markets. However, the transition to com- 
puters has not been without its challenges. Computer algorithms 
sometimes interact in unintended ways and markets have suffered 
disruptions that remain difficult to explain. 

In response to this challenging market structure, CETC staff 
began work several years ago to address the rise of automated 
trading across its markets. Since 2012, CETC staff has held 
roundtables, participated in advisory committee hearings, put for- 
ward a concept release, and no doubt held countless other smaller 
meetings. Regulation Automated Trading represents the culmina- 
tion of all this work hard work. 

Reg AT is summarized as a comprehensive approach to reducing 
risk and increasing transparency in automated trading. While I am 
certainly supportive of reducing risks and increasing transparency, 
the approach proposed by the Commission falls short of those goals. 

Reg AT’s vague boundaries and prescriptive requirements con- 
spire to create a rulemaking that is overly complicated, yet still in- 
complete. However, the rule does not have to be this complicated. 
The most confusing parts of Reg AT; the source code rules, the reg- 
istration regime, the reporting requirements, and the inflexible risk 
controls, are unnecessary to achieve the Commission’s stated goals. 
Market participants already have incentives to police bad algo- 
rithms, prevent disruptions, and plan for recovery. In many cases, 
there are already ongoing processes across the industry to impose 
and refine risk controls. 

A more modest proposal by the Commission might start by 
leveraging these inherent incentives and requiring universal adop- 
tion of a flexible framework for best practices. 

While I believe the instincts and intentions of the rule are good, 
its broad scope and sweeping requirements lead me to conclude 
that it cannot be implemented in its current form. I am heartened 
that Chairman Massad is open to finalizing the rule in phases, tak- 
ing more time to get it right. I look forward to seeing the Commis- 
sion’s next proposal. 

I have additional thoughts in my written statement, but for now, 
let me close by thanking today’s witnesses, each of whom have 
traveled from out-of-town to be here today. We appreciate your tak- 
ing the time to prepare the testimony, and your willingness to 
share your expertise with us, and I want to thank you. 

[The prepared statement of Mr. Conaway follows:] 
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Prepared Statement of Hon. K. Michael Conaway, a Representative in 
Congress from Texas 

Good morning, and welcome to the Committee’s hearing on Regulation Automated 
Trading. 

Over the past 3 decades, our financial markets have been quietly revolutionized 
by computers. Sometimes called the “electronification” of markets, computer net- 
works have slowly replaced the traditional trading pits. Electronic markets allow 
computers to seamlessly input orders, giving rise to trading directed and conducted 
entirely by computer algorithms. 

Electronic markets and algorithms offer easier access, reduced transaction costs, 
and support sophisticated tools that even the smallest market participants use. 
Today, algorithmic trading is essential to our futures markets. However, the transi- 
tion to computers has not been without its challenges. Computer algorithms some- 
times interact in unintended ways and markets have suffered disruptions that re- 
main difficult to explain. 

In response to this changing market structure, CFTC staff began work several 
years ago to address the rise of automated trading across its markets. Since 2012, 
CFTC staff has held roundtables, participated in advisory committee hearings, put 
forward a concept release, and no doubt held countless other smaller meetings. Reg- 
ulation Automated Trading represents the culmination of all this work hard work. 

Reg AT is summarized as “a comprehensive approach to reducing risk and in- 
creasing transparency in automated trading.” While I am certainly supportive of re- 
ducing risks and increasing transparency, the approach proposed by the Commission 
falls short of those goals. 

Requiring firms to provide the CFTC and the Department of Justice with on-de- 
mand access to sensitive intellectual property is fraught with danger. There is a le- 
gitimate fear among market participants that allowing more people, even regulators, 
to view and store their intellectual property increases their cybersecurity risks. 

While the rule is unclear about the CFTC’s intentions, at least one interest group 
interpreted the rules to suggest that the CFTC will use its newly self-granted au- 
thority to “involve itself in the workings of [automated trading systems] to antici- 
pate problems . . .” Such an interpretation of the rule would require CFTC staff to 
oversee hundreds of algorithmic trading companies, each running dozens of inter- 
dependent algorithms, each written with tens of thousands of lines of code. It isn’t 
a stretch to say that using source code to “anticipate problems” in the marketplace 
would require CFTC analysts to interpret hundreds of millions of lines of code. 

The CFTC cannot perform even a fraction of that work in any meaningful way. 
Yet, absent such a proactive effort to monitor algorithms, it is unclear why else the 
Commission would require source code be produced without a subpoena. 

Reg AT creates a definition, the AT Person, to identify the entities covered by the 
rule which must comply with all of the registration, reporting, testing, compliance, 
control, and source code repository requirements. Included in that definition are any 
entities already registered by the CFTC and “engaged in algorithmic trading,” as 
well as those registered as floor traders. 

Twenty-five years ago, this Committee sought to prevent individuals with felonies 
from trading in the pits by requiring the individuals trading for their own account 
in futures pits to register as floor traders, be fingerprinted, and undergo background 
checks. 

Under Reg AT, this concept is being re-purposed to tiy and expand the categories 
of registered market participants, despite no Congressional change to the current 
registration requirements. 

Beyond the obvious legal question, there is a practical problem to using the floor 
trader definition in this way: the new definition of floor trader could wind up unin- 
tentionally capturing thousands of end-users as AT Persons. 

Reg AT’s vague boundaries and prescriptive requirements conspire to create a 
rulemaking that is overly complicated, yet still incomplete. 

However, the rule does not have to be this complicated. The most confusing parts 
of Reg AT — the source code rules, the registration regime, the reporting require- 
ments, and the inflexible risk controls — are unnecessary to achieve the Commis- 
sion’s stated goals. Market participants already have incentives to police bad algo- 
rithms, prevent disruptions, and plan for recovery. In many cases, there are already 
ongoing processes across the industry to impose and refine risk controls. A more 
modest proposal by the Commission might start by leveraging these inherent incen- 
tives and requiring universal adoption of a flexible framework for best practices. 

While I believe the instincts and intentions of the rule are good, its broad scope 
and sweeping requirements lead me to conclude that it cannot be implemented in 
its current form. I am heartened that Chairman Massad is open to finalizing the 
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rule in phases and taking more time to get it right. I look forward to seeing the 
Commission’s next proposal. 

I’ll close by thanking today’s witnesses, each of whom traveled from out of town 
to be here today. We appreciate you for taking the time to prepare testimony and 
your willingness to share your expertise with us. Thank you. 

With that, I’ll turn to the Ranking Member for his remarks. 

The Chairman. With that, I will turn to the Ranking Member for 
his remarks. Collin. 

OPENING STATEMENT OF HON. COLLIN C. PETERSON, A 
REPRESENTATIVE IN CONGRESS FROM MINNESOTA 

Mr. Peterson. Thank you, Mr. Chairman, and I thank the wit- 
nesses for being here. 

A little more than 6 years ago, broad-based stock indexes col- 
lapsed and then rebounded over a course of about V 2 an hour. The 
Dow dropped by 998 points in a few minutes, and this was the 
largest infra-day point decline in its history. 

Subsequent research by the CFTC and the SEC determined three 
factors combined to cause this flash crash: algorithmic trading ac- 
tivity, obscure order submission methods, and an automated trade 
execution program to sell 75,000 stock index futures. 

Since the flash crash, there have been between 15 and 30 similar 
disruptions every single year in markets ranging from treasuries to 
crude oil to agriculture futures. With Regulation Automated Trad- 
ing, the CFTC has proposed some rules to try to prevent future 
market disruptions caused or made worse by algorithmic trading. 
This rulemaking is still open, and the CFTC is continuing to work 
on this, hopefully to get it right. 

So I hope that this hearing adds to our understanding of this 
complex issue, and assists the CFTC in its rulemaking. 

I look forward to today’s testimony, and I yield back. 

The Chairman. Well, I thank the Ranking Member for his com- 
ments. 

The chair would request that other Members submit their open- 
ing statements for the record so our witnesses may begin their tes- 
timony, and to ensure that there is ample time for questions. 

We have asked witnesses today who actually have to live with 
and/or are living with this rule, to give us as close to an insider 
look at the impact the rules will have as we can. 

We have Mr. Greg Wood, Chair, FIA Market Access Committee, 
Washington, D.C. We have Richard Gorelick, CEO of RGM Advi- 
sors, LLC, in Austin, Texas. Andrew Vrabel, Executive Director, 
Global Investigations, the CME Group, Chicago, Illinois. And Mr. 
Michael Ryan, the Executive Vice President and General Counsel, 
Trading Technologies International, in Chicago as well. 

Mr. Wood, the floor is yours for 5 minutes. 

STATEMENT OF GREGORY JOHN WOOD, CHAIRMAN, MARKET 

ACCESS COMMITTEE, FUTURES INDUSTRY ASSOCIATION; 

DIRECTOR, ELECTRONIC AND ALGORITHMIC EXECUTION, 

LISTED DERIVATIVES, DEUTSCHE BANK SECURITIES INC., 

WASHINGTON, D.C. 

Mr. Wood. Chairman Conaway, Ranking Member Peterson, and 
Members of the Committee, thank you for holding this very timely 
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hearing on the Commodity Futures Trading Commission’s proposed 
Regulation Automated Trading. 

My name is Greg Wood, and I am here today representing the 
Futures Industry Association. I currently serve as the chair of the 
FIA Market Access Committee, the co-chair of the FIA Market 
Technology Division’s Automated Trading Committee, and I pre- 
viously served as President of the FIA Market Technology Division 
itself 

FIA has heen working with the industry since well before the 
2010 flash crash to establish safeguards for electronic trading. We 
have published five documents that include best practices, rec- 
ommendations for risk controls, as well as the development, test- 
ing, and monitoring of trading software. 

FIA employed ten working groups devoted to analyzing the feasi- 
bility of the CFTC’s proposed Reg AT, and provided recommenda- 
tions for improving the regulation prior to finalization. Our efforts 
have involved the market participants, the exchanges, the futures 
commission merchants who act as facilitators for clients seeking to 
access the cleared derivatives markets, as well as other industry 
associations that represent various market constituents. 

Our efforts have been comprehensive, and are outlined fully 
within my written testimony, which also includes points that will 
be discussed further by my fellow witnesses, such as concerns re- 
garding the source code provisions of the proposed rule, as well as 
the complications that arise from the use of third-party-provided 
software. 

For the sake of time today, I will focus my comments on FCMs 
and their views, particularly with regards to pre-trade risk con- 
trols. 

U.S. futures markets have evolved into highly sophisticated elec- 
tronic markets, and all market participants have a responsibility 
appropriate to their participation in the life of an order to help 
minimize the likelihood of a market disruption. For that reason, 
pre-trade risk controls are the responsibility of all market partici- 
pants, and when implemented properly and appropriate to the na- 
ture of the activity, have been proven to be the most effective safe- 
guard for the markets, and should be applied comprehensively to 
all electronic orders, not just those of AT persons. 

Rather than defining what constitutes an AT person, and using 
an artificially constructed trigger to require registration of those 
participants, we believe that the most important tool for achieving 
the goal of protecting market integrity is requiring the application 
of pre-trade risk controls to all electronic orders, regardless of the 
participant’s registration status. Rules should not focus on any one 
specific type of market access, but rather should recognize the ap- 
propriate application of pre-trade risk controls to protect market in- 
tegrity. Regulations should build on and leverage the very success- 
ful risk controls and safeguards currently in place, instead of pro- 
posing new and untested systems or procedures that would require 
significant investment by the industry. Requirements should not be 
one-size-fits-all. Distinctions should be based on the business struc- 
ture, business model, operational size, and technical sophistication 
of market participants, and the specific implementation and loca- 
tion of particular risk controls should not be mandated by the 
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CFTC. Instead, the types of controls required should be principles- 
based to provide for flexibility, as well as to permit innovation and 
technological advances that could improve future controls. 

While we believe the CFTC can accomplish its objectives in Reg 
AT without new registration requirements by applying risk controls 
to all electronic trading, as previously discussed, we understand 
that the CFTC is concerned that it may be unable to enforce rules 
regarding automated trading against non-registrants. Thus, in an 
effort to be responsive to the CFTC’s concerns, FIA has joined with 
other trade associations to propose a requirement that all electronic 
trading must pass through the pre-trade controls of a CFTC reg- 
istrant. These controls are typically in addition to the risk controls 
provided at the DCM level. The responsibility for implementing the 
appropriate pre-trade risk controls lies either with the FCM reg- 
istrant that is facilitating electronic access to the DCM, or in the 
case of a market participant that is not trading through the risk 
controls of an FCM, with that participant, who is also a registrant. 
In both cases, these pre-trade risk controls must be supplemented 
by DCM-provided risk controls configured by the clearing member 
that grants access to the DCM. 

Required controls must meet the core principles of being de- 
signed to reasonably mitigate the potential for sending orders for 
too large a size to the DCM, sending orders for a clearly erroneous 
price to the DCM, and sending too many messages to the DCM. 

We believe that the recommended approach I have outlined re- 
flects a thoughtful effort designed to most effectively mitigate dis- 
ruptions in the ever-evolving markets regulated by the CFTC. 

Again, I would like to thank you for holding this important hear- 
ing. Oversight of the CFTC is such an important function of this 
Committee, and we commend you for the time devoted to these 
matters. I will be happy to answer any questions, following my fel- 
low panelists’ testimony. 

[The prepared statement of Mr. Wood follows:] 

Prepared Statement of Gregory John Wood, Chairman, Market Access 

Committee, Futures Industry Association; Director, Electronic and 

Algorithmic Execution, Listed Derivatives, Deutsche Bank Securities Inc., 

Washington, D.C. 

Chairman Conaway and Ranking Member Peterson thank you for holding this 
very timely hearing on the Commodity Futures Trading Commission’s (CFTC) Pro- 
posed Regulation Automated Trading (Reg AT). My name is Greg Wood and I am 
here today representing the Futures Industry Association (FIA). FIA’s members 
have been extremely engaged in providing input to the CFTC as it seeks to finalize 
Reg AT. I currently serve as the Co-Chair of the FIA Market Technology Division 
Automated Trading Committee, the Chair of the FIA Market Access Committee, and 
I previously served as President of the FIA Market Technology Division. 

FIA has been working with the industry since well before the 2010 Flash Crash 
to establish safeguards for electronic trading. We have published five documents 
that include best practice recommendations for risk controls, developing, testing and 
monitoring software, and other protections. 

FIA employed ten working groups devoted to analyzing the feasibility of the 
CFTC’s proposed Reg AT and providing recommendations for improving the regula- 
tion prior to finalization. Our efforts have involved the trading community, the ex- 
changes, market participants and the futures commission merchants (FCM), who act 
as facilitators for clients seeking to access the cleared derivatives markets. In March 
of 2016, FIA filed a comprehensive comment letter to address the various compo- 
nents of the proposal. Subsequently, and in response to a recent CFTC Staff Round- 
table, FIA has also worked with the Managed Funds Association, SIFMA Asset 
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Management Group, and the International Swaps & Derivatives Association (to- 
gether “the Group”) to present a view that has broad agreement across the industry. 
Further details can be seen within the Group’s comment letter submitted on June 
24th. 

Today, I will focus my comments on FCMs and their views, particularly with re- 
gards to pre-trade risk controls. 

During the course of a recent CFTC Staff Roundtable, Staff sought to elicit sug- 
gestions on how to better define Direct Electronic Access (DEA) as well as proposals 
for quantitative measures to reduce the current population of AT Persons to which 
Reg AT would apply. In addition, the Staff questioned whether requiring and moni- 
toring compliance by AT Persons could be imposed upon FCMs or designated con- 
tract markets (DCMs). Roundtable participants soundly rejected these proposals, as 
they did not address the real issues and concerns on which the Commission and Reg 
AT should be focused. 

Broadly, across all components of proposed Reg AT, the Group believes that: 

1. Pre-trade risk controls are the responsibility of all market participants, 
and when implemented properly and appropriate to the nature of the activity, 
have been proven to be the most effective safeguard for the markets, and 
should be applied comprehensively to all electronic orders, not just those of 
AT Persons. 

2. Rules should not focus on any one specific type of market access, but, rather, 
should recognize the appropriate application of pre-trade risk controls to pro- 
tect market integrity. 

3. Regulation should build on and leverage the very successful risk controls and 
safeguards currently in place instead of proposing new and untested sys- 
tems or procedures that would require significant investment by the industry. 

4. Requirements should not be one-size-fits-all. Distinctions should be based 
on the business structure, business model, operational size, and technical so- 
phistication of market participants. 

5. Rules should not be prescriptive. 

I would like to highlight the following Three key points that FIA feels should be 
considered in formulating a regulation that is both scalable and effective: 

First, Risk Controls. U.S. Futures markets have evolved into highly sophisti- 
cated, electronic markets, and all market participants have a responsibility appro- 
priate to their participation in the life of an order to help minimize the likelihood 
of a market disruption, and, accordingly, all electronic trading should be subject to 
appropriate pre-trade risk controls. 

Rather than defining what constitutes an AT Person, and using an artificially con- 
structed trigger to require registration of those participants, we believe that the 
most important tool for achieving the goal of protecting market integrity is requiring 
the application of pre-trade risk controls to all electronic orders, regardless of the 
participant’s registration status. To be clear, we are not opposed to a regulation cat- 
egory subject to appropriate requirements for that group of registrants; however, we 
believe defining a particular group of people and applying risk controls only to reg- 
istrants does not safeguard markets to the full extent the industry believes is need- 
ed. To that effect, the Group believes: 

• Each market participant’s orders should be subject to pre-trade risk 
controls, depending on how the market participant accesses a DCM. Ac- 
cess can be via self-developed software, a third party provided system or FCM- 
administered ^ software and/or services. Orders from market participants 
leveraging FCM-administered systems, including those provided by third par- 
ties, may utilize pre-trade controls administered by the FCM. 


^Such pre-trade risk controls can be implemented directly by the market participant or may 
be administered by the FCM facilitating electronic access to the market — including those imple- 
mented within third-party vendor systems or exchange provided graphical user interfaces that 
the FCM has administrative control over. 

2 It is important to note that a customer may use the same FCM to provide both execution 
and clearing services (“full-service FCM”) or may use one FCM for execution (“executing FCM”) 
and choose to clear their trades through another FCM (“clearing FCM”) by arranging for the 
trades to be given up to the clearing FCM by the executing FCM. In this instance, the executing 
FCM acts as the “gatekeeper” to the DCM matching engine, and, as such, is the only FCM that 
can administer risk controls at a pre-trade level. Any other FCM(s) that may subsequently clear 
trades for the customer can only provide risk controls on a post-trade basis once the trades have 
been given in from the executing FCM. 
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It is important to note that the Group believes that market partici- 
pants not using software that includes FCM-administercd risk controls 
should he responsible for applying risk controls to their own orders. 

• FCMs facilitating electronic access to a DCM should be responsible for 
implementing appropriate pre-trade risk controls for all electronic 
trading that passes through those controls that it administers. This can 
be accomplished by pre-trade risk controls provided by the FCM itself, or those 
provided by software that the FCM has administrative control over.^ Where a 
market participant is responsible for the administration of risk controls pursu- 
ant to Reg AT, the FCM may satisfy this responsibility by administering DCM 
hosted risk controls. 

• The risk controls proposed in the proposal are too prescriptive. The spe- 
cific implementation and location of particular risk controls should not be man- 
dated by the CFTC. Instead, the types of controls required should be principles- 
based to provide for flexibility as well as to permit innovation and technological 
advances that could improve future controls. 

• Identical pre-trade risk controls need not be applied at all points in the 
order flow. Pre-trade risk controls should not be duplicated in precisely the 
same manner across the order flow between market participants and DCMs. 
Pre-trade risk control requirements should permit flexibility such that the con- 
trols will be appropriate for their location and the type of electronic access being 
provided, with varying degrees of sophistication and granularity depending on 
who is setting the controls. 

• The standard used to measure compliance should be that pre-trade risk 
controls mitigate the risks associated with electronic trading — rather 
than attempt to completely prevent them. 

Based on these points, the Group proposes a requirement that all electronic trad- 
ing must pass through the pre-trade risk controls of a CFTC registrant — either the 
market participant itself, or the FCM that facilitates electronic access to the DCM. 
These controls are typically in addition to the risk controls provided at the DCM 
level. The details of this proposal are as follows: 

• Scope of Proposal: All electronic trading must be subject to pre-trade and 
other risk controls administered by a CFTC registrant that are appropriate to 
the nature of the activity. The responsibility for implementing the appropriate 
pre-trade risk controls lies either: 

(a) with the FCM registrant that is facilitating electronic access to the DCM, 
or 

(b) in the case of a market participant that is not trading through the risk con- 
trols of an FCM, with that participant, who is also a registrant. 

In both cases, these pre-trade risk controls must be supplemented by DCM- 
provided risk controls configured by the member of the DCO that grants access 
to the DCM. 

• Required Pre-Trade Risk Controls: Required controls must meet the core 
principles of being designed to reasonably mitigate the potential for: 

1. Sending orders for too large a size to the DCM; 

2. Sending orders for a clearly erroneous price to the DCM; and 

3. Sending too many messages to the DCM. 

• Identification of Covered Trades/Participants: Market participants trading 
electronically, without passing through FCM-administered risk controls, either 
self-identify to applicable DCMs prior to trading, or may be identified via tags 
on order messages. 

• Due Diligence Requirement: An FCM must perform due diligence on any 
customer to which it grants electronic access to the DCM without going through 
risk controls administered by the FCM. Such due diligence may include — for ex- 
ample — a self-certification by the market participant that their orders are sub- 
ject to appropriate pre-trade and post-trade risk controls. For the avoidance of 
doubt, such due diligence requirements do not make the FCM responsible for 
ensuring their customers’ compliance with their own regulatory obligations. 


3 Note that administration of such controls may be delegated by the FCM to another party, 
such as an introducing broker. 
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Second, Annual Reports. Reg AT’s proposed requirement of annual reports to be 
prepared by market participants and clearing member FCMs is ineffective, unneces- 
sary, and redundant with other requirements to which registrants are subject. Addi- 
tionally, the proposed reports will inundate DCMs with voluminous policies and pro- 
cedures related to the development and compliance of algorithmic trading systems, 
as well as mountainous snapshots of stale quantitative risk parameter settings par- 
ticularized to a given market participant that will be virtually impossible for a DCM 
to meaningfully assess. Accordingly, the Group believes that the objectives of the 
proposed rule can be met less onerously and more practically by requiring affected 
parties solely to certify that they materially comply with relevant aspects of the 
rule and to make such certifications available to a DCM or the CFTC upon request. 

Third, Source Code. The Source Code requirement for unfettered access to any 
firm’s intellectual property as proposed is unprecedented among regulators and 
threatens commercially valuable intellectual property and proprietary trading strat- 
egies. The Source Code requirement in the proposed rule puts highly proprietary in- 
formation at risk without measurable benefits. Required production of Source 
Code should only be available through a legal process where an owner of Source 
Code has the right to petition a court for appropriate protection. There is no suffi- 
cient set of access conditions (e.g., onsite review, tracking who reviews Source Code, 
etc.) that would adequately offset the dire potential commercial consequences of re- 
quiring production of Source Code absent the protection of legal process. 

Again, I would like to thank you for holding this important hearing. Oversight 
of the CFTC is such an important function of this Committee and we commend you 
for the time devoted to these matters. I will be happy to answer any questions fol- 
lowing my fellow panelists’ testimony. 

Appendix 

How Customers of FCMs Access Markets 

A market participant may choose to access a DCM via several channels (please 
refer to Diagram 1 for examples). Many market participants may use a combination 
of channels to facilitate different types of trading, using tools that are appropriate 
to the type of activity that they engage in. With very few exceptions, an executing 
FCM facilitates electronic access for the customer, and administers pre-trade risk 
controls appropriate to the type of access. 

1. In the context of electronic trading, an Application Programming Inter- 
face (API) is an interface for electronic access provided by one party for an- 
other party to connect directly without using a manual means of placing or- 
ders and receiving executions (see Graphical User Interface). 

Examples of APIs include the following — 

An API provided by a DCM for market participants to connect di- 
rectly to the matching engine. Such APIs are usually proprietary to the 
DCM, and will offer functionality such as types of messages, order types, 
etc., that is specific to the DCM. Connection to the API is overseen by the 
DCM through a certification process. Subsequent to CFTC 1.73, the DCM 
provides pre-trade risk controls to the FCM that facilitates electronic access 
(see O on attached diagram). 

The FCM administers pre-trade risk controls provided to them by the 
DCM, but greater responsibility lies with the market participant to imple- 
ment their own pre-trade risk controls to mitigate the possibility of inad- 
vertent market disruption. 

(a) An API provided by an FCM for market partieipants to conneet 

via the FCM infrastrueture, with orders subsequently routed via the 
FCM’s Automated Order Routing System (AORS) through to the DCM’s 
API. Such APIs are usually based on the FIX Protocol, a global standard 
for the exchange of financial information across asset classes. An FCM’s 
API may be used for routing orders directly from a customer’s trading 
system or from a third-party trading system without using a manual 
means of placing orders and receiving executions (see Graphical User 
Interface). 

Pre-trade risk management for orders routed through an FCM’s API 
is provided by the FCM before the order is subsequently routed to the 
DCM (see © O on attached diagram). 

(b) An API provided by a third-party software provider for market 
partieipants to conneet via their infrastructure, with orders subse- 
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quently routed via the software provider’s Automated Order Routing Sys- 
tem (AORS) through to the DCM’s API. Such APIs are usually based on 
the FIX Protocol, a global standard for the exchange of financial informa- 
tion across asset classes. A software provider API is used for routing or- 
ders directly from a customers’ trading system or from a third-party trad- 
ing system without using a manual means of placing orders and receiving 
executions (see Graphical User Interface). 

Pre-trade risk management for orders routed through a software pro- 
vider’s API is provided in their system before the order is subsequently 
routed to the DCM (see © on attached diagram). Such risk controls are 
typically administered by the FCM facilitating access to the DCM via 
the software provider.’^ 

2. In the context of electronic trading, a Graphical User Interface (GUI) is 
an interface for access provided by one party for another party to manually 
place orders and visually receive executions. 

Examples of GUIs include the following — 

(a) A GUI provided by a DCM for market participants to place orders 
directly on the DCM. Such GUIs are usually provided for functionality 
that is unique to the DCM and/or may not be readily available via the 
DCM API. In this situation, the DCM is acting as a software provider, 
and pre-trade risk management for orders entered though such a GUI is 
administered by the FCM facilitating access. 

(b) A GUI provided by an FCM for market participants to place or- 
ders directly with the FCM, with orders subsequently routed via the 
FCM’s Automated Order Routing System (AORS) through to the DCM’s 
API. Pre-trade risk management for orders routed through such a GUI 
is provided and administered by the FCM before the order is subse- 
quently routed to the DCM (see © O on attached diagram). 

(c) A GUI provided by a software provider for market participants to 
place orders directly via their infrastructure, with orders subse- 
quently routed via the vendor’s Automated Order Routing System (AORS) 
through to the DCM’s API. Pre-trade risk management for orders routed 
through such a GUI is provided by the software provider before the order 
is subsequently routed to the DCM (see © on attached diagram). Such 
risk controls are typically administered by the FCM facilitating access to 
the DCM. 

3. An Automated Order Routing System (AORS) is software designed to 
electronically route orders to a DCM, without any subsequent discretion in 
how to work the order. Any discretion regarding how to work an order based 
on parameters provided by a trader or customer — for example using algo- 
rithmic execution functionality — should be considered “algorithmic trading” 
and considered differently from an AORS. 

AORSs are utilized by many types of market participants, and typically 
offer pre-trade risk management functionality. It is important to under- 
stand who administers the pre-trade risk controls. 

Types of AORS include the following: 

(a) An AORS provided by an FCM where orders may be entered via 
an API or GUI and subsequently routed to the DCM’s API (see © 
O on attached diagram) using the FCM’s membership on the DCM. Such 
a system may be developed in-house at the FCM or licensed from a third- 
party provider, but in either situation, the AORS is considered part of the 
FCM’s infrastructure. Pre-trade risk controls are provided and adminis- 
tered by the FCM on a customer-by-customer basis. The FCM in this sce- 
nario is always the executing FCM, though they may also be the clearing 
FCM based on their customer relationship. 

(b) An AORS provided by a software provider where orders may be 
entered via an API or GUI and subsequently routed to the DCM’s 
API (see © on attached diagram) using an FCM’s membership on the 


^Note that where a non-FCM clearing member of a DCM uses a software provider to access 
the market, via either API or GUI, there is no second line of pre-trade risk control administered 
by an FCM. In such a situation where the non-FCM clearing member sets their own pre-trade 
risk controls, additional responsibility may be required on the market participant to ensure that 
all appropriate steps are taken to mitigate the possibility of inadvertent market disruption. 
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DCM. The software provider gives FCMs the ability to permission the 
customer to trade and set the appropriate risk limits. Although such a 
system is not fully under the control of an FCM, especially where the 
AORS provides access to multiple FCMs, it can still be considered an ex- 
tension of the FCM’s infrastructure because a customer may not trade 
until the FCM sets appropriate pre-trade risk controls. As such, pre-trade 
risk controls are administered by the FCM on a customer-hy-customer 
basis. The FCM in this scenario is always the executing FCM, though 
they may also be the clearing FCM based on their customer relationship. 

An AORS utilized by a market partieipant where orders may be entered 
via an API or GUI and subsequently routed to the DCM’s API (see O on at- 
tached diagram). Such a system may be developed in-house by the market partici- 
pant or licensed from a software provider, but in either case is considered part of 
the participant’s infrastructure. Pre-trade risk controls are administered directly by 
the participant, and not by an FCM. The AORS is certified by the DCM to connect 
directly to its API, and access is facilitated by an FCM via its membership on the 
DCM. The FCM in this scenario is always the executing FCM, though they may also 
be the clearing FCM based on their customer relationship. 

Sample Pre-Trade Risk Control Locations 


Market ParTiopants<MP) canuseS wavs to accessaDesigttated Contact Market (DCM). arKUnav also use 
multiple Futures Commission Merchants (FCM) to facilitatethat access AutomatedTradir^SvstemsiATS) 
can be implementedat various points in the order flow. FCM facilitating electronic access implement risk 
controls appropriate to the type access 


the DCM through 


3. Direct access 
FCM administered 3'° Party Vendor 
Market Participants can trade via S'” 
partvvertdor-provided GUI or API 
FCMsadmimster pre-trade risk 
controisprovided to them bv the 3” 
party. The3'“party mayalsoprovide 
anATS for Market Participantsto 
executetheir orders 
Examples: 

BloombergTradebook CQG, Trading 
TechtvMogies 


' MortetParticipants rftor do not ufWre FCM 
pre-trode risk controls should ensure that they 
implement appropriate pre-trade controls. 



4. FCM provides indirect access to 
the DCM via its infrastructure 
Market Participants can trade via 
FCM* provided GUI. API or via 
instruCTiontotheFCM execution 
desk The FCM mav also provide an 
ATSforusebv Market Participants 
to execute their orders 
The FCM may buld these services 
or license a scft.vare provider, 
such as Fidessa.ObjeaTradingor 
TradingTechnologies 


5. Indirect access to the DCM via 
FCM Infrastructure 
Market Paiticipants ctm trade via 
3'’partvverKlor*provided GUI or 
APIthatthen routes to an FCM* 
provided API The vendor may 
al so provi de an ATS f or Market 
Partici pants to execute their 
orders 
Examples: 

BloombergEMSX. FlexTrade, 
Inforeach. Poitware. RealticK 
REDI, Tethvs. Trading Screer\ 


For indirect access via the FCM core or co-located infrastructure 
the FCMimpiements pre-trode risk controls. 



n 

Co-located 


Direct Access 

■ 

Market 

I 

Participant 


\ 



DCM 

Matching 

Engine 


1. Direct access to the exchange 
viaOCM-providedAPt 
TheMarket Participant may buld or license 
asoftwareprovidersuchas Obfect 
Tradlng.TradingTechrK>logies or ULLINK 



2, Indirect access to theexchai^e via co-located FCM 
Market Gateway and FCM-provided API 


DCM Data Center 


The Chairman. Thank you. 

Richard, 5 minutes. 

STATEMENT OF RICHARD GORELICK, J.D., CHIEF EXECUTIVE 
OFFICER, RGM ADVISORS, LLC, AUSTIN, TX 

Mr. Gorelick. Thank you, Chairman Conaway, Ranking Mem- 
ber Peterson, and Members of the Committee. Thank you for the 
opportunity to discuss the CFTC’s proposed Reg AT. I will briefly 
summarize my written statement now, which I ask be included in 
the record. 

I am the CEO of RGM Advisors, a proprietary trading firm that 
I co-founded in 2001, that trades electronically in a variety of mar- 
kets. We are based in Austin, Texas, where we employ about 100 
people. I serve on the CFTC’s Technology Advisory (Committee, and 
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I am involved in industry efforts to enhance trading risk manage- 
ment and public policy. I have advocated for a regulatory environ- 
ment that promotes fair competition, encourages innovation, im- 
proves transparency, manages systemic risk, lowers cost for inves- 
tors and end-users, and gives regulators the tools that they need 
to detect and deter abuses. 

Mr. Chairman, I support the Commission’s stated aims in Reg 
AT, however, I am concerned that the proposal falls short of 
achieving them. The rule could amount to a lot of work by the in- 
dustry and by the Commission, and at best, accomplish only small 
gains in market integrity. We are fortunate that the industry has 
already put in place multiple layers of risk controls. New rules 
should be principles-based and they should be flexible, because 
technology changes quickly. And since pre-trade risk controls are 
the most effective safeguard for market integrity, all electronic or- 
ders should be subject to them, regardless of the type of market 
participant or their registration status. 

Reg AT tries to accomplish too much in a single regulation. I 
support the recommendation of commenters to simplify the rule- 
making by dividing it into separate parts, focusing first on pre- 
trade risk management. 

One part that should be considered separately is the Commis- 
sion’s proposal to create a new requirement for certain market par- 
ticipants to register with the Commission. Setting aside the curious 
decision to register these automated traders, many of whom never 
set foot on a trading floor, as floor traders, this requirement is un- 
necessary to accomplish the Commission’s risk management objec- 
tives. My written testimony discusses the principles that should 
guide any automated trading regulation, and includes discussion of 
several other provisions in Reg AT. 

I would like to turn to my concern with the rule’s treatment of 
source code. Source code is an automated trading firm’s secret 
sauce. It comprises very specific and detailed computer instructions 
that embody the firm’s unique trading strategies. Source code often 
includes valuable trade secrets, developed at significant expense, 
that directly impact business competitiveness. The requirement to 
turn over valuable intellectual property to the government on de- 
mand would be unprecedented and unreasonable. The proper treat- 
ment of IP is central to our private enterprise system. The secret 
formula for Coca-Cola is not available to the FDA simply upon re- 
quest. The source code for Google’s search algorithms is not avail- 
able to the government without due process. Government agencies 
must make a reasonable showing of cause and use a subpoena to 
get access to private proprietary information. A trading firm’s 
source code should be no different. 

For most purposes, source code reviews would be incredibly cost- 
ly for the CFTC. Trading firms have large and complicated code 
bases that change regularly. As an example, my relatively small 
firm has over one million lines of source code associated with our 
current trading system. We make changes almost daily. To review 
source code of multiple firms at any scale would require an army 
of computer programmer regulators. The benefits to the CFTC of 
reviewing source code would, in most cases, be very limited. It is 
implausible that reviewing source code as part of an audit or sur- 
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veillance program would help the CFTC prevent market disrup- 
tions, or provide meaningful insight into how a trading system 
would operate when interacting in a real market. In most cases, 
surveillance of electronic audit trails presents a much more valu- 
able and cost-effective way to understand trading activity. 

I can imagine circumstances in which a regulator would have a 
legitimate interest in reviewing parts of a firm’s source code. How- 
ever, under those limited circumstances, the regulator should be re- 
quired to use a subpoena and put in place appropriate safeguards. 
As we all know, any agency taking possession of source code could 
raise significant cybersecurity concerns. 

Finally, allowing easy government access to source code would 
set a dangerous precedent with foreign governments, such as 
China, who seek to impose similar requirements on U.S. firms. We 
are hopeful that this provision will be revised. 

Thank you for the opportunity to testify, and I welcome the Com- 
mittee’s interest in this rulemaking. 

[The prepared statement of Mr. Gorelick follows:] 

Prepared Statement of Richard Gorelick, J.D., Chief Executive Officer, 
RGM Advisors, LLC, Austin, TX 

I. Introduction 

Chairman Conaway, Ranking Member Peterson, and Members of the Committee, 
thank you for the opportunity to join you today to discuss the Commodity Futures 
Trading Commission’s (CFTC’s or the Commission’s) proposed regulation on auto- 
mated trading, or “Reg AT” as it is commonly known. ^ I am pleased to be with you 
today to discuss this significant regulatory proposal. 

I am the CEO of RGM Advisors, a trading firm located in Austin, TX, that I co- 
founded in 2001. RGM Advisors is a technology-focused, quantitative trading firm 
that trades in a variety of equities and futures markets. We use computers to ana- 
lyze tremendous amounts of market data, to determine what trades we want to 
make, to conduct those trades, and to manage risk. We have about 100 employees 
and most of our staff are software developers, information technologists, and quan- 
titative researchers. Most of our software systems have been developed in-house. 
Our firm, like many in our sector, trades on a proprietary basis, using our own cap- 
ital to take short-term positions in thousands of instruments. 

I serve on the CFTC’s Technical Advisory Committee (TAC) and I am a member 
of the FIA Principal Traders Group (FIA PTG) executive committee. My written tes- 
timony today expands on public comments I have shared with the CFTC TAC^ and 
it reflects many of the views that FIA PTG has expressed to the Commission.^ 

I have been involved in industry-led efforts to develop best practices and guide- 
lines on identifying and mitigating the risks of automated and electronic trading. 
Since 2010, FIA has published six papers related to these important topics. As a 
member of the TAC, I have reviewed and commented on CFTC’s proposed regulation 
of automated trading since before the Commission first began considering its initial 
concept release. 

The progression of automated trading has provided substantial benefits to our 
markets. Increasing automation and competition have helped to improve market 
quality, increase transparency, and lower costs for investors, hedgers and end-users 
of all sizes. As we recognize and work to enhance the many benefits of automated 
trading, we must also ensure that rules and regulations keep pace with techno- 
logical innovation. I have long been a strong advocate for a regulatory environment 
that promotes fair competition, encourages innovation, enhances transparency, man- 
ages systemic risk, lowers costs for investors and hedgers, and gives regulators the 
tools they need to detect and deter abuses. 


^Proposed Regulation Automated Trading, 80 FR 78824 (Dec. 17, 2015). 

2 See http:! / www.cftc.gov / idc ! groups ! public / @newsroom / documents ! file I tac 02231 6_tran 

script.pdf page 29 

^See https:! j fia.org j sites i default i files i content attachments i 2016-03-16_Regulation 

Comment_Letter.pdf and https:! ! fia.org ! sites ! default ! files ! 2016-06-24_RegAT_Roundtable_ 
Group_Comment.pdf. 
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I am supportive of the Commission’s stated aims in developing Reg AT, which are 
to mitigate the risks arising from algorithmic trading activity, to increase trans- 
parency with respect to exchange programs and activities, and to update Commis- 
sion rules in response to the evolution from pit trading to electronic trading. I ap- 
preciate the substantial effort put forth by the Commission staff in drafting this pro- 
posal. 

While these goals are laudable, the proposed rule, as it currently stands, falls 
short of achieving these goals, and is overly complicated, costly, and confusing. Some 
aspects of the proposed rule are too broad, while others are too narrow to ade- 
quately address risks. I am concerned that the rule could amount to quite a lot of 
work by the industry and by the Commission to accomplish disproportionately small 
gains in market integrity, while introducing significant potential negative unin- 
tended consequences. 

In my testimony, I will first set out generally accepted principles for the regula- 
tion of automated trading and then share substantive concerns with proposed Reg 
AT. 

II. Principles for Regulation of Automated Trading 

There is broad industry consensus on the principles that should guide any regula- 
tion of automated trading. 

First, it is critical to recognize and leverage the substantial risk controls and safe- 
guards that have already been put in place by the industry. The CFTC’s TAC has 
provided a forum to explore current industry practices with respect to electronic 
trading. In addition to detailed discussions of industry best practices for risk man- 
agement, exchanges (CME and ICE, in particular) have presented thoughtful risk 
controls and extensive surveillance capabilities in great detail. New regulation 
should build on the existing framework that has proven successful, and should not 
try to reinvent that framework. 

Second, to be effective and relevant to dynamic market conditions and practices, 
regulations cannot and should not be overly prescriptive. Instead, as has been the 
CFTC’s historical practice, regulators should adopt principles-based rules that allow 
for flexibility to distinguish between different activities, business structures, and 
technologies of market participants, as well as changing market conditions, among 
other factors. Technology changes quickly, so it is important that the rules are able 
to stand the test of time. 

Third, and most critical, pre-trade risk controls are the most effective safeguard 
for market integrity. Therefore, they should be applied comprehensively to all elec- 
tronic orders, not just certain orders submitted by certain types of businesses or 
submitted through certain types of market access. Simply put, all electronic orders 
should be subject to risk controls, not just those from certain types of market par- 
ticipants. To do otherwise would create loopholes and blind spots. 

To be clear, the application of risk controls to every order does not require every 
market participant to implement its own risk controls. The policy should be to en- 
sure that all orders are subject to appropriate risk controls that can be provided in 
various ways by market participants, clearing firms, or exchanges. 

III. Specific Concerns with Proposed Reg AT 

With respect for the CFTC’s significant work on this rule, I believe Reg AT tries 
to accomplish far too much in a single regulation, making it unwieldy and imprac- 
tical. To address this, I support the idea of simplifying the rulemaking by breaking 
it up into separate components, in order of importance: (1) pre-trade and other risk 
controls, (2) policies and procedures for the development, testing, deployment and 
monitoring of algorithmic trading (including third-party software), and (3) if nec- 
essary, registration of certain market participants. 

Considering these components separately would allow the Commission to focus 
first on the parts of Reg AT that are most important to market integrity and widely 
supported by industry participants: pre-trade and other risk controls. Separating the 
rulemaking would also allow the CFTC to determine the proper scope for each area 
of regulation. 

My specific concerns with Reg AT fall into the following categories: the scope of 
the proposal, unnecessary registration requirements, and access to intellectual prop- 
erty, including source code, without due process. 

A. The Scope of Reg AT Is Too Broad in Some Parts and Too Narrow in Others 

One of the stated goals of the proposed rule is to reduce the risks of automated 
trading. To accomplish this, it introduces a myriad of requirements, both technical 
and operational in nature, for newly defined “AT Persons.” 

Rather than starting from the principle that all electronic orders must be gov- 
erned by certain risk controls, the rule proposal attempts to cover a limited class 
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of market participants within the definition of an AT Person. Consequently, the rule 
would establish a class of market participant that would not be required to have 
risk controls in place despite having a similar ability to impact market integrity. 
As a result, the rule may fail in its primary goal of protecting the market. 

In other areas, the Commission’s proposal is too broad. In particular, the rule 
would impose a wide range of very specific requirements pertaining to how AT Per- 
sons manage their automated trading operations. These requirements include de- 
tailed rules for development, testing, documentation, monitoring, training, compli- 
ance and reporting across several dimensions of a firm’s operations. While some of 
these requirements roughly track industry best practices, others do not, and most 
of these requirements are burdensome and do not clearly contribute to market integ- 
rity. 

As just one example, the proposal includes a provision that would require AT Per- 
sons to produce an annual report detailing all changes to their risk settings during 
the course of a year and to deliver that annual report to the exchanges on which 
they traded. It is not unusual for firms trading hundreds of products to change their 
risk limits multiple times per day. These changes are often made in an exchange- 
based interface managed by a clearing firm, and as a result, the clearing firm and 
the exchange know about the risk limit changes in real time. While it would amount 
to a lot of work for AT Persons to produce these annual reports and for exchanges 
to review them, it is hard to see what additional information would be commu- 
nicated in the process, or how risk management would be improved. Such onerous 
requirements would both inhibit an AT Person’s ability to innovate compared to 
non-AT Persons with similar businesses, and also dramatically increase the cost of 
maintaining algorithmic trading operations. These costs would certainly be passed 
on to market end-users in the form of higher transaction costs and less liquid mar- 
kets. 

Moreover, some of the proposed definitions are, in my opinion, too broad and, as 
a result, may be counterproductive. Much of the proposed rule is geared toward pre- 
venting “Algorithmic Trading Events” which are defined to include both “Algo- 
rithmic Trading Compliance Issues” and “Algorithmic Trading Disruptions.” As a re- 
sult of these definitions, the more comprehensive a firm’s policies, the more liability 
it would risk if any practice were found to have varied from its written policy. Ra- 
tional actors would be incented to have fewer internal controls, rather than more. 
Similarly, the rule would prohibit firms from “disrupting or materially degrading” 
their own trading. This requirement might encourage firms to continue trading in 
the face of potential risk management issues. In my opinion, those provisions should 
be eliminated from their respective definitions. 

B. The Registration Requirements Are Unnecessary 

The CFTC is proposing to create a new requirement for certain market partici- 
pants trading solely for their own account and using automation to register with the 
Commission as floor traders. Setting aside the curious decision to register these 
automated traders, many of whom never set foot on a trading floor, as “floor trad- 
ers,” this requirement is unnecessary. Exchange rules and industry best practices 
already require some types of pre-trade risk management for all market participants 
regardless of registration category. The trading activity by the market participants 
that would be covered by this requirement is already managed through exchanges 
and there is no gap in risk controls. The CFTC has the legal authority and should 
apply appropriate risk management requirements broadly to all market participants 
whether or not they are registered with the Commission.^ 

I support comments by FIA, FLA PTC, and other industry associations explaining 
that registration requirements are unnecessary. I reiterate that any market partici- 
pant, regardless of registration status or type of trader, has the potential to disrupt 
markets. It should be noted that when the SEC studied market disruptions (or so- 
called mini-flash-crashes) they noted that the majority of such events were caused 
by human mistakes, such as fat-finger errors, rather than algorithmic trading bugs. 
In addition, if the Commission would start from the basic principle that all elec- 
tronic orders should be subject to risk controls, and that these requirements should 
not hinge on registration status, the entire rule would become much less complex 
to design and implement. 


'^The Commission already has ample legal authority to impose requirements on non-reg- 
istrants that trade on U.S. futures markets in order to prevent disruptive practices expressly 
described in Section 4c(a)(5) of the Commodity Exchange Act (“CEA”), as well as “any other 
trading practice that is disruptive of fair and equitable trading.” Using this authority, the CFTC 
has a statutory basis to enact rules to require all traders (whether registered as AT Persons 
or not) to comply with requirements meant to avoid prohibited conduct. 
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Should the CFTC be determined to implement a new registration requirement, 
then such registration should be considered separately and apart from the proposed 
pre-trade risk controls in proposed Reg AT, so its potential effects can be given full 
and careful consideration. Any registration requirement should be based upon a new 
and more suitable registration category rather than over-loading the existing “floor 
trader” category created for individual market participants standing on a trading 
floor.® At a minimum, the Commission should delay adoption of any registration re- 
quirement until after it has implemented other components of Reg AT to evaluate 
the necessity of registration, which would be costly for new registrants and the 
Commission, and would be a burdensome distraction for the National Futures Asso- 
ciation (NFA). 

C. Source Code Should Only be Available to the Government with Due Process 

The final concern I would like to raise today is the CFTC’s proposed access to 
source code. The proposed requirement to turn over valuable intellectual property 
(IP) to the government on demand is simply unprecedented and unreasonable. The 
proper treatment of IP lies at the heart of our private enterprise system. As noted 
by CFTC Commissioner Giancarlo in connection with the issuing release for Reg 
AT,® the secret formula for Coca Cola is not available to the FDA, certainly not on 
demand. The source code for Google’s search algorithms is not available to the gov- 
ernment without due process. Government agencies must make a reasonable show- 
ing of cause and get a proper court order, such as a subpoena, to gain access to in- 
tellectual property. 

A trading firm’s source code should be no different. Most modern trading firms 
are very much technology businesses. Many of our staff write software, and our 
source code constitutes important trade secrets and valuable IP about our future 
business plans. Modern trading firms invest significant time, effort and money in 
technological innovation, much of which is embodied in source code, and they go to 
great lengths to protect its confidentiality and their competitive edge. Not only 
would this proposed provision set a troubling precedent for government access to 
private information, but it would do so without any demonstrable regulatory bene- 
fits to offset the significant risk associated with the misappropriation of that intel- 
lectual property. 

Proposed Reg AT would accomplish this unprecedented access by classif 3 dng 
source code as “books and records” which would make them available to the Com- 
mission and the Department of Justice upon request. Source code, however, is un- 
like other books and records such as trade blotters and similar records, which can 
be reasonably protected with standard confidentiality. Source code often is com- 
prised of valuable trade secrets that represent substantial investment and innova- 
tion and can directly impact the competitiveness of a business. 

It should be recognized that for most purposes, source code reviews would be in- 
credibly costly for the CFTC. Trading firms have very large and complicated code 
bases that change very often. As an example, my firm is a relatively small trading 
firm. We have over a million lines of source code associated with our current trading 
systems. This code has been written over 15 years in about ten different program- 
ming languages. We make changes of one kind or another almost daily. To review 
source code of multiple firms at any scale would require an army of computer pro- 
grammer regulators. 

The benefits to the CFTC of reviewing source code would, in most cases, be very 
limited. It is not plausible that reviewing source code as part of an audit or surveil- 
lance program would somehow help the CFTC prevent future market disruptions or 
provide any meaningful insight into how a trading system would operate in a real 
market when interacting with other traders in different market conditions. In most 
cases, surveillance and analysis of electronic audit trails (such as orders, fills, and 
cancellations) would present a much more valuable and cost effective way to under- 
stand trading activity. 


®See http:/ 1 comments.cftc.gov I PublicComments I ViewComment.aspx?id=60765 (“Even if the 
Commission disagrees and decides that registration is necessary to ensure compliance with the 
Proposal, CME Group questions whether the Commission has sufficient legal authority under 
the CEA to require registration as a ‘floor trader’ of a new type of distinctly non-floor trader. 
Historically, the scope of CFTC registrants has only heen expanded when Congress provides the 
Commission with new statutory authority. [. . .] In the absence of such new authority from 
Congress, the Commission proposes to introduce otherwise unregistered algorithmic traders who 
access an exchange through DEA into an existing statutory registration category. CME Group 
is not persuaded by the Commission’s argument that Congress could have intended for the defi- 
nition of ‘floor trader’ to include only this subset of algorithmic traders.”) 

® See http: / /www. cftc.gov / idc / groups / public / @newsroom / documents ! file / transcript 

112415.pdf, page 39. 
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I can imagine circumstances in which a government agency, such as the CFTC, 
would have a legitimate interest in reviewing parts of a firm’s source code. For ex- 
ample, in an enforcement action for market abuse, reviewing portions of source code 
might provide some insight into the intent behind the placement of certain orders. 
However, under those limited circumstances, the Commission should be required to 
get a subpoena, and put in place appropriate safeguards. To the extent that the 
CFTC takes possession of any source code, this would raise significant information 
security concerns. 

Moreover, allowing easy government access to source code would set a dangerous 
global precedent with foreign governments, such as China, who are seeking to im- 
pose similar source code requirements on U.S. firms. In fact, the Federal Govern- 
ment recently emphasized the importance of intellectual property by signing the De- 
fend Trade Secrets Act into law in order to enhance protections against the mis- 
appropriation of intellectual property. This development has not gone unnoticed. In 
fact, a number of technology and business-focused industry organizations have 
raised this exact point in formal comments to the CFTC.'^ 

We are hopeful that this provision will be revised. CFTC Chairman Massad has 
indicated that the Commission “take[s] very seriously the fact that [the information] 
is proprietary, it is significant of value to firms, and . . . [we] would certainly . . . 
do everything [the CFTC] can to protect confidentiality.”® As such, the current prac- 
tice — which enables the CFTC or Department of Justice to seek a voluntary produc- 
tion of source code subject to agreed restrictions, or to request such source code via 
a validly issued subpoena in connection with a formal investigation — is sufficient 
and should be continued. 

I understand that some regulators have worried that trading firms might not ade- 
quately retain their source code in such a way that they could make it available 
for inspection. While good software development practices already lead firms to re- 
tain their source code in software control systems, I believe it would be helpful for 
the Commission to work with industry groups to establish a principles-based reten- 
tion policy for source code based on current practices that would ensure regulators 
have access to source code information when needed.® This would allow businesses 
to maintain control over their sensitive intellectual property while ensuring regu- 
lators can access information that they desire, after following appropriate processes. 

TV. Conclusion 

Altogether, proposed Reg AT would impose costly burdens on market participants, 
without commensurate benefits. Our markets are dynamic and constantly changing. 
Mandated risk controls, like those in Reg AT, which are overly specific, could quick- 
ly become obsolete as markets, technology, and trading strategies evolve. Creating 
checklists and written policies might give the appearance of reform, but in practice, 
do not make markets safer or more resilient — and could instead create unintended 
incentives to the contrary. 

The trading community has a direct interest in well-functioning and resilient mar- 
kets. We want to comply with the rules of the road. We welcome improvements that 
actually make the markets safer and more efficient. However, when rules serve to 
impede those goals, we need to reconsider them. I am concerned that proposed Reg 
AT, as designed, would not accomplish its stated objective of protecting market in- 
tegrity, because it would leave many electronic orders outside of its scope. Moreover, 
this proposed regulation, as currently written, would be costly for market partici- 
pants and the Commission. These costs would ultimately be borne by market end- 
users in the form of higher transaction costs and less liquidity. Finally, the source 
code access provisions put valuable American intellectual property in jeopardy, are 
without precedent, and would have a chilling effect on technology both inside and 
outside of the derivatives world. 

I appreciate the opportunity to testify before you today and I welcome the Com- 
mittee’s interest in consideration of this rulemaking. I look forward to answering 
any questions you may have. 

Thank you. 


[Attachment] 

June 24, 2016 

Via CFTC Website: http: ! I comments.cftc.gov 


^See http:! I comments.cftc.gov / PublicComments IViewComment.aspx?id=60890&. 

® See http: / / www.cftc.gov ! idc ! groups ! public i @newsroom I documents ! file / transcriptOBl 0 

16.pdf, pages 295-296. 

® See https:! i fia.org j sites i default i files i 2016-0G-24_RegAT_Roundtable_Group_Comment.pdf , 
page 9-10. 
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Christopher Kirkpatrick, 

Secretary of the Commission, 

Commodity Futures Trading Commission, 

Washington, D.C. 

RE: RIN 3038-AD52 — Joint coalition comments in response to CFTC Pro- 
posed Regulation AT souree code provisions 

Dear Mr. Kirkpatrick: 

The U.S. Chamber of Commerce (the “Chamber”), the Information Technology In- 
dustry Council (“ITI”), the Business Software Alliance, the International Swaps and 
Derivatives Association, the Futures Industry Association (“FIA”), the FIA Principal 
Traders Group, Modern Markets Initiative, and the Software & Information Indus- 
try Association write to you in strong opposition to the source code disclosure and 
retention requirements contained in the Commodity Futures Trading Commission’s 
(the “CFTC”) notice of proposed rulemaking on Regulation Automated Trading 
(“Regulation AT”) ^ and urge you to entirely eliminate these requirements from the 
final version of the rule. 

In short, if not significantly amended, the proprietary source code provisions of 
Regulation AT will: 

(1) compromise the established and expected due process rights of our members; 

(2) increase the threat of “copycat” measures from other countries and contradict 
established U.S. policy on intellectual property disclosure; 

(3) heighten the possibility of cyberattacks against government-mandated data 
repositories; and 

(4) do little to assist the CFTC in its market surveillance activities. 

While this letter is not an exhaustive listing of all of the issues of our associations 
may have with Regulation AT, we believe that it is important that the CFTC appre- 
ciate the broad-based opposition we have to Regulation AT’s proprietary source code 
provisions.^ We elaborate in additional detail below. 

Mandating On-Demand Access to Proprietary Source Code Tramples Fun- 
damental Due Process Rights and Attracts Similar Global Responses 

Our chief concern with Regulation AT relates to the unprecedented, on-demand 
access that the CFTC would have to the proprietary source code of market partici- 
pants engaged in algorithmic trading. Simply put, the proposed requirements force 
the disclosure of valuable intellectual property to the government based only on a 
showing that is akin to a document request. That type of requested access con- 
tradicts widely held expectations of due process associated with highly sensitive in- 
tellectual property — and, indeed, the legal protections that apply to any intellectual 
property in the U.S. 

While the CFTC has recently acknowledged these concerns at a staff roundtable, 
there is no clear explanation as to why the CFTC could not use well-established 
U.S. judicial process to obtain access to proprietary source code data when needed. 
The CFTC and the DOJ have long used subpoenas to obtain access to non-public 
information and can continue to do so here. However, Regulation AT would provide 
an end-run around these important protections, eroding the important due process 
rights of these market participants. 

Even more concerning is the precedent that the Regulation AT source code provi- 
sions would set, which may invite similar requirements in other countries. As re- 
cently as last year, the United States pushed back against a comparable proposal 
issued by the China Banking Regulatory Commission, which would have required 
American companies selling computer equipment to Chinese banks to turn over in- 
tellectual property and submit source code.^ This action is also consistent with the 
U.S. Government’s policy against source code disclosure requirements in other con- 
texts, as evidenced by previous opposition to proposed regulations issued by India’s 
Department of Telecommunications relating to 2009-2010 Telecom Network Equip- 
ment Certification requirements, and by Korea’s National Intelligence Service in 


1 Commodity Futures Trading Commission, 80 Fed. Reg. 242 (proposed Dec. 17, 2015) (to be 
codified at 17 CFR Parts 1, 28, 40, et al.). 

2 For additional detail, please see letter of March 16, 2016 to CFTC on Proposed Regulation 
AT source code provisions, available at the following link Qittps: II wwiv.itic.org ! dotAsset j 
469665b9-7552-4763-9569-b835eb81a585.pdf). 

^Paul Mozur and Jane Perlez, China Halts New Policy on Tech for Banks, N.Y. Times, Apr. 
16, 2015, available at http:! Iwww.nytimes.com 1 2015 ! 04! 17 ! business ! international ! china-sus- 
pends-rules-on-tech-companies-serving-banks.html? _r=0. 
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2005 relating to sales of information security software to Korean Government agen- 
cies. Moreover, the signatories to the Trans-Pacific Partnership have also agreed not 
to require the transfer of, or access to, source code of software owned hy a person 
of another party as a condition for the import, distribution, sale, or use of such soft- 
ware.'^ 

These policy decisions from other parts of the U.S. Government demonstrate a 
strong expression of U.S. Administration policy to defend the rights of intellectual 
property holders from unnecessary disclosure to third parties, including government 
entities. It also signals the extent to which the CFTC is a relative outlier compared 
to other financial services and capital markets regulators, and certainly with respect 
to other instrumentalities of the U.S. Government. We believe that the CFTC should 
follow these decisions when finalizing Regulation AT, recognize the important of in- 
tellectual property to these firms, and respect the due process rights of its regulated 
entities. 

Mandating On Demand Access to Proprietary Source Code Is Inefficient 
and Will Not Assist the CFTC 

Proprietary source code data is extremely difficult to understand without its de- 
veloper, and simply viewing the source code on demand would not assist the CFTC 
in determining if automated trading contributed to a market-wide event. Partici- 
pants at the CFTC’s roundtable on June 10 noted that source code differs substan- 
tially from “books and records” requirements, in that proprietary source code does 
not solely provide information on instructions. Instead, it tells the story behind 
“why” and “how” a decision is made — much of which is impossible to understand 
without recreating a scenario event with the assistance of a developer. 

Consequently, we fail to see how the CFTC’s on demand access requirements will 
actually assist the agency in its market surveillance and investigative activities. In 
addition, the CFTC has not provided an estimate of the costs for hiring qualified 
developers that could actually analyze the proprietary source code, meaning that the 
CFTC currently does not know how much it would even cost to review information 
within its possession. We question the value of requesting on demand access to pro- 
prietary source code when the CFTC may not even have the resources to analyze 
it. 

Regulation AT Increases the Potential for Cyberattacks and Threatens the 
Security of Proprietary Source Code 

As proposed. Regulation AT requires automated trading firms to maintain source 
code repositories to manage source code access, maintain copies of production code 
(as well as logs of changes to production code), and include an audit trail to deter- 
mine who made changes to source code, under what circumstances, and why.® Such 
repositories must be available for inspection by the CFTC, the DOJ, and potentially 
third parties. 

We strongly object to mandating automated trading firms to create source code 
repositories under the terms established by Regulation AT, especially when many 
companies already maintain such information. Moreover, establishing the same 
across-the-board requirement unintentionally makes those repositories “cyber tar- 
gets,” giving hackers and others a precise location for obtaining an automated trad- 
ing firm’s most valuable intellectual property. 

Moreover, there is substantial reason to believe that proprietary source code data 
would not be safe in a government-mandated repository or in the hands of the Fed- 
eral Government. In the past year, we have seen cyberattacks against the Internal 
Revenue Service,® the Office of Personnel Management,'^ the Federal Deposit Insur- 
ance Company,® and the Board of Governors of the Federal Reserve.® Even the 


^See Article 14.17: Source Code, Trans-Pacific Partnership (ICT Annex), available at 
https: I i ustr.gov / sites ! default I files / TPP-Final-Text-Electronic-Commerce.pdf. 

®See supra note 1 at p. 78824. 

® Stephen Dinan, IRS hit by cyberattack, thousands of taxpayers’ information stolen, The 
Washington Times, May 26, 2015, available at http: II www.washingtontimes.eoml news 12015 ! 
may 1261 irs-hit-cyberattack-thousands-taxpayers-informatio / . 

^Julianne Pepitone, Federal Data Breach: Can the Government Protect Itself From Hackers?, 
NBC News, Jun. 5, 2015, available at http: 1 1 www.nbcnews.com I tech I security I federal-data- 
breach-can-government-protect-itself-hackers-n370556. 

® Joe Davidson, FDIC cyberattacks included hit on former chairwoman’s computer. The Wash- 
ington Post, May 11, 2016, available at https:! ! www.washingtonpost.coml news! powerpost! 
wpl201 6105(11 Ifdic-cyberattacks-included-hit-on-former-chairmans-computer / . 

® David Murphy, House Committee Investigates Federal Reserve Cyber-Attacks, PC Mag, Jun. 
4, 2016, available at http: 1 1 www.pcmag.com I news 1 344991 1 house-committee-investigates-fed- 
eral-reserve-cyber -attacks. 
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CFTC suffered its own data breach in June of 2012, risking the security of its em- 
ployees’ [Slocial [Slecurity [N]umbersJ° Given how incredibly valuable proprietary 
source code data would potentially be in the hands of a hacker, we believe that 
these data breaches are enough reason for the CFTC to eliminate this element of 
Regulation AT. 

Conclusion 

While we appreciate the CFTC’s need for timely access to data in order to fulfill 
its market surveillance mission, the proprietary source code requirements of Regula- 
tion AT are a bridge too far. By mandating on demand access to proprietary source 
code and the development of source code repositories, the CFTC not only com- 
promises established due process rights — it also adopts policy in direct contradiction 
to other agencies of the U.S. Government and increases the risk of cyherattack, all 
while not providing any tangible benefit to the CFTC. Consequently, we believe that 
the proprietary source code provisions of Regulation AT should be eliminated in 
their entirety. 

Sincerely, 

BSAlThe Software Alliance; 

Information Technology Industry Council; 

International Swaps and Derivatives Association; 

Futures Industry Association; 

FIA Principal Traders Group; 

Modern Markets Initiative; 

Software & Information Industry Association; 

U.S. Chamber of Commerce. 

The Chairman. Thanks, Richard. 

Mr. Vrabel, 5 minutes. 

STATEMENT OF ANDREW VRABEL, J.D., EXECUTIVE 

DIRECTOR, GLOBAL HEAD OF INVESTIGATIONS, 

MARKET REGULATION DEPARTMENT, CME GROUP, INC., 

CHICAGO, IL 

Mr. Vrabel. Thank you, Chairman Conaway, Ranking Member 
Peterson, and Members of the Committee. My name is Andrew 
Vrabel, I am the Global Head of Investigations at CME Group 
where my teams are responsible in part for monitoring CME’s mar- 
kets for aberrant market activity, including activity that may be 
the result of automated trading strategies. 

I am pleased to be here today to discuss the CFTC’s proposed 
rule on automated trading, referred to as Reg AT. As many of you 
may be aware, automated trading strategies, or algorithmic trad- 
ing, is a source of considerable liquidity in today’s markets. These 
are strategies that are used by all types of participants, from com- 
mercial end-users to market makers, for price discovery and effi- 
cient risk management. But like any automated process, there are 
inherent risks associated with automated trading, and it is because 
of this, and CME Group’s vested interest in preserving the integ- 
rity of our markets, that we have pioneered innovative market con- 
trols, and have devoted substantial resources to protect the market 
from potential aberrations and disruptions. 

On top of these measures, which have proven highly effective 
over time, Reg AT aims to mandate additional tools and controls 
which we, unfortunately, think are broad, unworkable, and could 
be counterproductive. 


^^Silla Brush, CFTC Data Breach Risks Employees’ Social Security Numbers, Bloomberg 
News, June 25, 2015, available at http:! lwww.bloomberg.com ! news! articles 12012-06-25 Icftc- 
data-breach-risks-employees-social-security-numbers. 
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One particular area of Reg AT that we have concerns with is a 
requirement that the exchanges implement tools and controls that 
would prevent algorithmic traders from committing a disruption in 
the marketplace. Unfortunately, this is an unachievable standard. 
The most robust tools imaginable cannot prevent all algorithmic 
trading disruptions, or all disruptions in the markets, for that mat- 
ter. Instead, we have proffered to the CFTC, and we believe that 
the exchanges, if required to do anything, should be to create tools 
and controls that would mitigate rather than prevent the potential 
for an algorithmic trading disruption in the markets. 

Relatedly, Reg AT would also require the exchanges to imple- 
ment tools that would prevent traders from committing compliance 
violations, most of which is already prohibited by the Commodity 
Exchange Act, carrying criminal penalties, and is also prohibited 
by CFTC’s regs and exchange rules. The exchanges have never 
been asked to mandate or create a control that would guarantee 
universal compliance. In my experience, people intent on violating 
the law will find a way to do so, whether there is a control in place 
or not. It is for this reason we have asked the CFTC to abandon 
this portion of Reg AT in its entirety. 

Reg AT also proposes that the exchanges review extensive com- 
pliance reports to identify and remediate deficiencies with risk con- 
trols, development, and testing standards. The weakness with this 
particular approach is that the information contained in those com- 
pliance reports is backward-looking. It will, therefore, be stale the 
moment the exchanges have an opportunity to review it. Beyond 
that, even if the exchanges are asked to review these extensive 
compliance reports, in order to do a substantive review of this type 
of information, it will require highly specialized skills and knowl- 
edge that, in our experience, is only possessed by the traders and 
firms that created the algorithms themselves. The exchanges are 
not suited, nor should they be, to perform this type of review on 
a regular basis. Instead, we believe that the clearing member firms 
that grant that particular participant access to the market is in a 
strong position to receive from that trader or trading firm a certifi- 
cation or a verification that they are in compliance with the re- 
quirements of Reg AT. Then, if necessary, the exchanges can ascer- 
tain the veracity of those certifications and verifications. 

One notable void in Reg AT with respect to market risk controls 
is that Reg AT would mandate them for only a certain subset of 
algorithmic traders; the so-called AT persons. The reason for this 
void we believe is that the CFTC is primarily intent on capturing 
a set number of new registrants. We believe that registration is a 
secondary concern that, if at all, should be addressed in a separate 
rulemaking. Instead, we think that the goal of Reg AT should be 
on the creation of flexible, not-mandated, market-wide risk controls 
that apply to every algorithmic trader order that is submitted to 
the exchange. 

We, therefore, submitted to the CFTC a proposal or an idea of 
a two-tiered system of market risk controls. One tier of risk con- 
trols could be administered by the algorithmic trader themselves or 
the clearing firm that provides them access to the marketplace, and 
another level of risk controls would be administered by the ex- 
change on a market-wide basis. These two levels of control would 
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provide the marketplace adequate, necessary, and maximum pro- 
tections from the potential of an algorithmic trading disruption. 

Last, you have heard from others and you will hear more on 
source code. I will keep our comment here specific and limited. The 
Commission has administrative subpoena authority under the 
Commodity Exchange Act, and this affords participants due process 
and a mechanism to preserve the confidentiality of that informa- 
tion. Given the sensitivity of source code, we see no reason why 
this approach shouldn’t be adequate to the CFTC on a going for- 
ward basis. 

While the concerns we raise with Reg AT are significant, we are 
hopeful that the CFTC continues to work with the marketplace as 
they have to create a better and stronger rule. 

On behalf of CME Group, I truly appreciate the opportunity to 
be here, and I look forward to answering any questions that you 
may have. 

[The prepared statement of Mr. Vrabel follows:] 

Prepared Statement of Andrew Vrabel, J.D., Executive Director, Global 

Head of Investigations, Market Regulation Department, CME Group, Inc., 

Chicago, IL 

Thank you. Chairman Conaway, Ranking Member Peterson and Members of the 
Committee. 

My name is Andrew Vrabel. I am the Executive Director of Global Investigations 
at CME Group, which is part of our Market Regulation division. I am pleased to 
present CME Group’s views on the CFTC’s proposed rules to enhance regulation of 
algorithmic trading, known as “Regulation AT.” ^ 

Algorithmic trading, a type of automated trading, is a source of considerable mar- 
ket liquidity today, facilitating price discovery and efficient risk management. Yet, 
as with any automated process, there are risks associated with algorithmic trading. 
To preserve and protect the integrity of our markets from these risks, CME Group 
has pioneered innovative risk controls and system safeguards, and continually em- 
ploys substantial human resources and technological capabilities for the develop- 
ment, implementation and enhancement of these controls. In my role, I see first- 
hand eveiy day the sophisticated tools our exchanges have developed and use to 
mitigate risks and protect our markets. 

Regulation AT aims to mandate additional standards for protections on top of the 
strong self-regulatory measures that our exchanges already apply. We are concerned 
that much of Regulation AT’s framework is overly broad in scope, unworkable and 
could be counterproductive. Our comment letters urge the CFTC to re-focus its pro- 
posal on the essential area of flexible, not mandated, market risk controls that can 
be tailored to the different business operations and roles of traders, intermediaries 
and exchanges to best protect market integrity.^ Getting Regulation AT right is 
critically important to all who use our markets. 

We identify the following key areas where the proposed rulemaking needs to be 
substantially refined: 

Regulation AT Should Not Require a Designated Contraet Market (“DCM” 
or “Exchange”) To Prevent Algorithmic Trading Disruptions or Algo- 
rithmic Trading Compliance Issues 

Our primary concern is that Regulation AT appears to require exchanges to pre- 
vent Algorithmic Trading Disruptions (“algorithmic trading disruptions”).^ As CFTC 
Chairman Massad, observed when approving the Proposal, no control — like no 


^See Regulation Automated Trading, 80 Fed. Reg. 78824 (December 17, 2015); see also Public 
Staff Roundtable on Elements of Regulation Automated Trading; Reopening of Comment Period, 
81 Fed. Reg. 36484 (June 7, 2016). 

^See Letter from CME Group to CFTC, re: Notice of Proposed Rulemaking on Regulation 
Automated Trading (RIN 3038-AD52), dated March 16, 2016. See Letter from CME to CFTC 
re: Reopening of Comment Period re: Regulation Automated Trading (RIN 3038-AD52), dated 
June 24, 2016. 

3 As used herein, “Algorithmic Trading Disruption” has the meaning contained in the Pro- 
posal. 
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rule — can always prevent disruptions and other operational problems that may arise 
from algorithmic trading.'^ We agree. As a result, we believe the “prevent” standard 
is unachievable. Instead, we urge the CFTC to adopt a standard that requires ex- 
changes to implement tools to mitigate the effects of an algorithmic trading disrup- 
tion. Any final rule text and accompan3dng preamble should consistently articulate 
this achievable objective for exchanges. 

Regulation AT also appears to require exchanges to prevent Algorithmic Trading 
Compliance Issues (“algorithmic trading compliance issues”).® The Proposal would 
require exchanges to prevent an event that causes a certain trader to operate in a 
manner that does not comply with the Commodity Exchange Act or its rules and 
regulations, rules of any exchange to which such algorithmic trader submits orders 
through algorithmic trading, the National Futures Association rules, the algorithmic 
traders own internal requirements, or the requirements of the trader’s clearing firm. 
We oppose this requirement for two reasons. First, as discussed below, we believe 
Regulation AT generally should not attempt to address compliance issues, but 
should instead focus on deterring algorithmic trading disruptions. Second, imposing 
this type of universal compliance obligation on DCMs is a major departure from 
DCMs’ traditional self-regulatory role Congress envisioned, as reflected in the Core 
Principles.® 

Exchanges have never been asked to guarantee, or provide tools to guarantee, the 
universal compliance by certain market participants because such a requirement 
would be unrealistic and unreasonable. People who intend on violating the law, Eed- 
eral regulation, or rule of a self-regulatory organization will find a way. Further, 
requiring an exchange to guarantee compliance and prevent algorithmic trading 
compliance issues could inadvertently create a safe-harbor in an enforcement action. 
If a trader or firm subsequently is accused of violating an exchange rule, CFTC reg- 
ulation, or provision of the Commodity Exchange Act, they could cite to an ex- 
change’s prior action (or inaction) in defense of the allegations. This could signifi- 
cantly undermine the effectiveness of an enforcement program and disciplinary ac- 
tion. 

What has proven effective is when exchanges operate in the self-regulatory role 
Congress envisioned, which includes adopting and enforcing rules of conduct related 
to trading. This serves to not only penalize wrongdoers where warranted but also 
to deter other would-be violators, whether they deploy algorithmic trading strategies 
or are manual, point-and-click traders. 

Requiring Exchanges To Review and Evaluate Annual Compliance Reports, 
Policies, and Procedures and Enforce Compliance With Regulation AT 
Is Unworkable and Beyond the Scope of an Exchange’s Role 

CME Group believes the Commission’s proposed requirement that certain algo- 
rithmic traders prepare and submit extensive annual compliance reports to ex- 
changes creates an unnecessary administrative burden and substantial costs on all 
parties involved without providing significant benefit to market integrity. There are 
many reasons that support removing this aspect of the Proposal. First, the informa- 
tion contained in the proposed compliance reports would be stale and not represent- 
ative of how a firm is currently addressing risks by the time the reviews are sub- 
mitted to an exchange. This renders the exchange review substantially ineffective 
at preventing or mitigating a future algorithmic trading event. 

Second, exchanges are not practically in a position to assess an algorithmic trad- 
er’s compliance with Regulation AT or issue remediation instructions. Assessing pre- 
trade risk controls designed to prevent or even mitigate an algorithmic trading 
event will be dependent on granular aspects of each algorithmic strategy, including 
inputs, variables, and calculations that inform the strategy; system architecture; 
operational infrastructure; and the skills and experience of each trader, pro- 
grammer, and developer. Not only is this information highly sensitive and propri- 
etary, but assessing these aspects will require highly specialized skills and knowl- 
edge possessed only by the traders or firms themselves. 

Finally, under the Proposal, a DCM’s review of a compliance report and remedi- 
ation instructions, if any, would seemingly endorse the policies, procedures, and risk 
control parameters. This imposes significant liability on the exchanges, and again, 
it potentially creates a safe-harbor if an issue subsequently arises. 


"^See Chairman Massad’s Statement on November 24, 2015 {http: 1 1 www.cftc.gov I PressRoom I 
SpeechesTestimony / massadstatementl 12415). 

®As used herein, “Algorithmic Trading Compliance Issues” has the meaning contained in the 
Proposal. 

® See Section 5fd) of the Commodity Exchange Act. 
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As the Commission is well aware, the CME Group exchanges rigorously scrutinize 
the trading on our markets each day pursuant to our commitment to protecting the 
integrity of our markets and compl3ring with existing DCM core principle require- 
ments. We routinely monitor the market and conduct exhaustive reviews of market 
events and other conduct that might be considered disruptive. As a matter of prac- 
tice, if an algorithm malfunctions and causes a disruption in the market, we conduct 
an in depth review of the participant’s risk controls, development and testing proce- 
dures, and compliance policies. We submit that this is the proper role of an ex- 
change and that the Commission should not force exchanges to change these well- 
functioning mechanisms as a result of Regulation AT. 

To the extent verification of an algorithmic trader’s compliance is needed, we be- 
lieve the clearing member that granted the trader access to the exchange would be 
better positioned to accept a certification of compliance as a condition precedent to 
granting that trader access to the market. 

We believe that a refined focus on the risk of market disruptions, e.g., algorithmic 
trading disruptions, would enable the Commission to establish a coherent and 
meaningful framework to address the risks presented by algorithmic trading. 

Pre-Trade Market Risk Controls Applied to all Algorithmic Traders 

CME Group proposes that two layers of pre-trade risk controls would apply to all 
algorithmic trading orders. The first layer would be administered by either the algo- 
rithmic trader itself or its clearing member that granted access to the exchange. The 
second layer would be developed and administered by the exchange. Both layers of 
market risk controls must he reasonably designed to mitigate the effects of algo- 
rithmic trading disruptions, and set at a level of granularity appropriately tailored 
to the underlying nature of the algorithmic trading activity such that the risk miti- 
gation standard is met. 

CME Group believes that all algorithmic traders should be subject to market risk 
controls. Proposed Regulation AT leaves a control void for some algorithmic traders 
by only requiring market risk controls for, the so-called “AT Persons.”'^ The reason 
for this gap is that the CFTC has focused primarily on attempting to capture a set 
number of new registrants. We believe registration is a secondary concern — the first 
aim of any rule in this area should be establishing a blanket of market risk controls 
that applies to all algorithmic trading in a consistent manner. 

We also believe the long-term effectiveness of any market risk control framework 
is dependent upon market participants being afforded flexibility to innovate as trad- 
ing technology evolves. Accordingly, CME Group’s alternative framework would not 
mandate the use of any specific market risk control measures. Rather, the rules 
would establish acceptable practices that market participants can follow in order to 
meet the applicable risk mitigation standard, consistent with the Commission’s his- 
tory of establishing acceptable practices in other areas of DCM core principle com- 
pliance. 

The Source Code Open Access Requirement Raises Serious Confidentiality 
Concerns 

Other industry representatives will testify about the source code issue. We agree 
with those who want to avoid undue, routine disclosure of their intellectual property 
to government officials. This provision raises serious concerns regarding the con- 
fidentiality of proprietary information. Currently, if the Commission has reason to 
believe that it needs access to a market participant’s source code, it can obtain the 
code subject to adequate confidentiality protections via the subpoena process. We 
know of no reason why this approach should not be satisfactory to the CFTC given 
the sensitivity of the information at issue. 

CME Group appreciates the opportunity to share our views on this important rule 
proposal. We remain hopeful that the CFTC will continue to work with all stake- 
holders to build a stronger and better rule. 

I look forward to answering any questions you might have. 

The Chairman. Thank you. 

Mr. Ryan, 5 minutes. 


used herein, the term “AT Person” has the meaning contained in the Proposal. 
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STATEMENT OF MICHAEL G. RYAN, EXECUTIVE VICE 

PRESIDENT AND GENERAL COUNSEL, TRADING 

TECHNOLOGIES INTERNATIONAL, INC., CHICAGO, IL 

Mr. Ryan. Good morning, Chairman Conaway, Ranking Member 
Peterson, and Members of the Committee. My name is Mike Ryan, 
and I am Executive Vice President and General Counsel of Trading 
Technologies International. We are commonly known as TT in the 
industry. 

TT is an independent software vendor, or ISV, of approximately 
400 employees. Our headquarters are in Chicago, and we have of- 
fices in most of the major financial centers around the world. 

TT licenses electronic trading systems that enable its customers 
to trade on the 45 major electronic exchanges and liquidity plat- 
forms globally. TT’s products, which are housed at our customers’ 
facilities or hosted by TT in co-location facilities, enable customers 
to trade using several automated tools, pointing and clicking on a 
market, or by inputting and utilizing their own proprietary algo- 
rithms to trade on electronic exchanges. 

As an ISV, I believe that TT provides a perspective on some of 
the issues related to the proposed Reg AT that is different than 
many of the other market participants represented here today. In 
that regard, I appreciate the opportunity to testify about some 
practical aspects of the regulation, and how it might be imple- 
mented using technology in place today. 

I will testify on the following three aspects of Reg AT: definition 
of direct electronic access, or DEA; the need for and propriety of a 
source code repository; and the testing requirements related to 
electronic trading applications. These are also addressed in my 
written testimony, which I ask to be included in the record. 

TT believes that the definition of DEA in Reg AT should be clari- 
fied to indicate that there is no direct electronic access where the 
orders are routed to an exchange through a clearinghouse mem- 
ber’s trading system, where pre-trade and other risk controls can 
be controlled by such a member, even where a trading firm or a 
third party maintains the physical location of the systems. Without 
clarifying the language, the definition of DEA will likely cause 
many single traders, small trading groups, and even larger com- 
mercial companies like energy firms and agricultural co-ops and 
merchants who hedge on futures exchanges, all of whom trade 
through DCO members, and are often substantial liquidity pro- 
viders, to have to register as floor traders. This will add layers of 
administrative complexity to their businesses, without advancing 
the risk oversight, because a DCO member’s oversight is already 
fully integrated into the available trading systems. 

Proposed Reg AT also requires AT persons to maintain a source 
code repository. Source code in a repository could be subject to the 
inspection by both the CFTC and the DOJ, without subpoena or 
any formal opportunity by a source code owner to object to endeav- 
or to restrict the manner or access or use of the source code. TT 
believes these requirements in the CFTC and DOJ’s inspection au- 
thority are unnecessarily and extraordinarily broad, not likely to 
provide helpful information, likely amount to an unconstitutional 
taking of individuals’ property, and are generally unnecessary to 
achieve the goal of the proposed regulations. 
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Source code of any trading firm or technology firm goes to the es- 
sence of the value of such companies. It is highly proprietary, 
trade-secret information that could expose the fundamental aspects 
of a business that provide economic advantage over competitors. 
Making such valuable intellectual property readily available to the 
Commission is unnecessary to fulfill the intent of the regulations. 

Source code is also complicated, and the breadth of the relevant 
code might be so expansive that it is hard to fathom how it would 
be compiled, stored, or used effectively by the Commission. A useful 
example of the underlying complexity of seemingly simple com- 
mands appears in our first comment letter to the Commission. 
Similarly, without the exact same market data flowing through it, 
the myriad software applications interacting together may not 
work the same. Replicating the market data is likely a bigger prob- 
lem than it seems because trading programs often coalesce data in 
various ways, depending on many factors. 

Even in the unlikely scenario where the code of an algorithm 
might be helpful, the subpoena power of the Commission would be 
more than adequate to ensure that the code is reviewed when truly 
necessary. 

The last issue that I want to address is the testing requirement 
set forth in Reg AT. TT believes that such testing should focus on 
the output of an algorithmic trading system, rather than the source 
code underlying such systems. As proposed, source code underlying 
an algorithmic trading system would be subject to substantial, 
highly prescriptive testing in advance of a system’s rollout, and 
continually thereafter. TT’s customers test algorithms every day, 
but the proposed language of Reg AT seems to require a registered 
entity to test software code as opposed to the finished product that 
the entity developed or licensed. To the extent the entity licensed 
the product from a third party, the source code is never available 
for testing, and TT sees no reason why the code should be required 
for testing. The reason why customers purchase turnkey software 
is to utilize the product as a whole. Testing of components of the 
source code is not consistent with that motivation, and doesn’t 
make achieving the goals of the CFTC any more likely. 

Thank you very much for the opportunity to testify before you 
today. I am happy to address any questions you may have. 

[The prepared statement of Mr. Ryan follows:] 

Prepared Statement of Michael G. Ryan, Executive Vice President and 

General Counsel, Trading Technologies International, Inc., Chicago, IL 

Good morning Chairman Conaway, Ranking Member Peterson, and Members of 
the Committee. My name is Mike Ryan and I am Executive Vice President and Gen- 
eral Counsel at Trading Technologies International, Inc. (“TT”). TT is an inde- 
pendent software vendor (“ISV”) of approximately 400 employees, we are 
headquartered in Chicago and have offices in most major financial centers through- 
out the world. TT licenses software trading solutions enabling its customers that in- 
clude the largest banks, commercial firms, hedge funds, proprietary trading firms 
and other professional traders to trade on 45 of the world’s major electronic ex- 
changes and liquidity platforms. TT’s electronic trading solutions, which are either 
housed at our customers’ facilities or hosted by TT in co-location facilities, enable 
TT customers to trade using several automated trading tools, pointing and clicking 
on a market, or by inputting and utilizing their own proprietary algorithms to trade 
on electronic exchanges. 

Most exchange-traded derivatives are now traded electronically, and electronic 
systems that connect to exchanges, as well as algorithmic trading, have introduced 
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new risks to markets that were not present in open-outcry environments. The daily 
increasing enhancements in processing and connection technologies including hous- 
ing trading strategies on servers that are co-located with exchange matching en- 
gines constantly accelerates the speed of trading to new levels and amplifies these 
risks. 

I am proud that TT has historically been in the forefront of helping the exchange- 
traded derivatives industry manage risks associated with electronic trading, by of- 
fering trading systems that include comprehensive risk-management features that 
can be administered by customers, but ultimately controlled by their futures com- 
mission merchants — who provide the gateway to derivatives exchanges. 

As an ISV, I believe that TT provides a perspective on some of the issues relating 
to the proposed Regulation Automated Trading (“Regulation AT”) that is different 
than many of the other market participants represented here today. In that regard, 
I appreciate the opportunity to testify before you and I hope that my testimony will 
help the Committee understand some practical aspects of the regulation and how 
it might be implemented using technology in place today. 

We have raised some concerns about Regulation AT in other formats, including 
through public comment letters ^ and today I would like to testify on the following 
three aspects of Regulation AT: 

(1) The definition of “Direct Electronic Access” (“DEA”); 

(2) The need for and propriety of a source code repository; and 

(3) The testing requirements relating to algorithmic trading applications. 

(1) Definition of “Direct Electronic Access” 

TT believes that the definition of DEA in Regulation AT should be clarified to in- 
dicate that there is no DEA where the orders are routed to a Designated Contract 
Market through the trading/order routing system of a member of a derivatives clear- 
ing organization (“clearing house” or “DCO”) where the pre-trade and other risk con- 
trols are able ultimately to be controlled by such member, including when a third 
party maintains the physical location of the systems. 

As drafted. Regulation AT defines DEA as an arrangement where a person elec- 
tronically transmits an order to an exchange without the order first being “routed 
through a separate person” who is a member of a clearinghouse to which the ex- 
change submits transactions for clearing. As proposed, any non-CFTC registered 
person engaging in the trading of futures or swaps through DEA would be required 
to register with the CFTC as a “Floor Trader” and be subject to a host of prescrip- 
tive requirements — as would all persons designated as “AT Persons” under the con- 
templated CFTC rules. 

However the proposed definition of DEA is unclear as it does not provide suffi- 
cient guidance as to what “being routed through a separate person” means. The defi- 
nition of DEA, as drafted, may suggest that the order would also have to be routed 
through a system physically controlled by the DCO member, but such physical con- 
trol really has nothing to do with actual control of risk management or the goal of 
enhancing risk management of such orders. The ultimate ability to exclusively con- 
trol risk parameters is the relevant issue and that is typically achieved remotely 
using software applications. For example, using TT systems, a risk administrator 
is able to sit at his or her desk in Chicago and set risk parameters for traders who 
may be physically located anywhere in the world. 

One suggestion for modifying the definition would be to add “(including through 
a system physically managed by a third party retained by such member to act on 
its behalD” after the phrase “who is a member of a derivatives clearing organiza- 
tion.” Such clarification would not diminish any DCO member’s ability to control 
risk, would reflect the manner by which such risk is often administered today and 
the legitimate goal of the new regulation would still be achieved. 

Without clarifying the language, the definition of DEA will likely capture within 
the definition of “Floor Trader” many single traders, small trading groups and even 
larger companies like energy firms and agricultural Co-ops and merchants who 
hedge on futures exchanges, all of whom trade through DCO members and are often 
substantial liquidity providers. The prescriptive requirements imposed on Floor 
Traders will add layers of administrative complexity to their businesses and require 
them to hire expensive compliance experts to their staffs. Yet, no further risk over- 
sight would be achieved because a DCO member’s oversight is already fully inte- 
grated into the available trading systems. 


^See attached Comment letters dated March 15, 2016 and June 24, 2016. 
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(2) Source Code Repository and CFTC/Department of Justice Inspection 

Authority 

Proposed CFTC Regulation AT also requires AT Persons to “maintain a source 
code repository to manage source code access, persistence, copies of all code used in 
the production environment, and changes to such code.” Source code in a repository 
would be subject to the inspection by both the CFTC and the Department of Justice 
(“DOJ”) without subpoena or any formal opportunity by a source code owner to ob- 
ject or endeavor to restrict the manner of access or use of the source code. 

Like many in the industry and at least one CFTC Commissioner, TT believes 
these requirements and the CFTC and DOJ’s inspection authority are unnecessarily 
and extraordinarily broad, not likely to provide helpful information, likely con- 
stitutes an unconstitutional taking of individuals’ property and is generally unneces- 
sary to achieve the goal of the proposed regulations. TT reco^izes that subsequent 
to the publishing of Regulation AT, the CFTC indicated publicly that it did not in- 
tend for the source code “repository” to be held by the Commission, but TT’s con- 
cerns remain. 

а. Source Code Is Highly Proprietary and Typically Not Made Available to Third- 

Parties 

Except with respect to open source licensing arrangements, to my knowledge 
source code is never licensed under any software license agreement offered by any 
software provider including any ISV in the futures or securities industries or any 
software firm such as Microsoft or Google. The source code of any trading firm or 
technology firm goes to the essence of the value of such companies. It is highly pro- 
prietary, trade secret information that could expose the fundamental aspects of a 
business that provide economic advantage over competitors. Making such valuable 
intellectual property readily available to the Commission is unnecessary to fulfill 
the intent of the regulations. The CFTC is no less prone to potential cybersecurity 
attacks than other government agencies and private companies, and two recently 
well-publicized instances provide real life examples of why firms would be gravely 
reluctant to turn over their proprietary source code to the CFTC or any government 
agency except under the highest level of protections. In each of these cases ex-gov- 
ernment regulators — one from the New York Federal Reserve Bank and the other 
from the Food and Drug Administration-obtained and shared confidential informa- 
tion from their ex-government employers with their then current private employers. 

б. Source Code Is Complicated and the Potentially Relevant Amount of Source Code 

Is Enormous 

Frankly, it is doubtful that source code would readily be useful to the Commis- 
sion. One engineer’s source code is rarely drafted in the same manner as another 
engineer’s and without proper documentation to help decipher the code it is often 
meaningless. Even with proper documentation it would often take insight from mul- 
tiple engineers to decipher the intent of the code and documentation. 

The breadth of the relevant code might also be so expansive that it is hard to 
fathom how it would be compiled, stored or used effectively. Each layer of code is 
very relevant to how an algorithm might function. Additionally, any number of dif- 
ferent coding languages might be used in each application and at each layer of soft- 
ware. TT, alone, uses over 30 different coding languages. 

A useful example of the underlying complexity of seemingly simple commands ap- 
pears in TT’s first comment letter to the Commission. 

i. Market Data Adds Another Level of Complexity 

Similarly, without the exact same market data flowing through it, the myriad 
software applications interacting together may not work the same. Replicating the 
market data is likely a bigger problem than it seems because trading programs 
often coalesce data. Moreover, how and when coalescing occurs may vary from mo- 
ment to moment depending on many factors such as network routers, firewalls, 
switches, server hardware, operating systems and vendor software. 

Multipl 3 dng the complexity exponentially, the Commission would likely have to 
replicate market data at a particular moment from multiple markets, because trad- 
ing algorithms will typically use and analyze data from many related markets, for 
example, equities and/or stock options if trading stock index futures. So, even if the 
Commission could recreate the prices in a market precisely as they were dissemi- 
nated by the exchanges or other relevant markets, the software would likely act dif- 
ferently on different occasions despite using the same market data. 

c. Making Source Code Readily Available to Regulators Would Not Reduce the Risks 

Even assuming, for the sake of argument, that the Commission could decipher the 
morass of relevant source code and the complexities of dealing with market data. 
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there is no compelling need to gain access to the code because it adds very little 
to reduce the risks of algorithmic trading. 

The outcome of the trades are indisputable evidence of the actual outcome of an 
algorithm and are already available in the form of the trade data (orders, fills, 
quotes sent to and matched at each exchange). Unusual results and/or repeated out- 
comes demonstrate the intent of traders and usually no more is necessary to estab- 
lish intent. 

The published guidance from exchanges and the CFTC regarding market manipu- 
lation cases recognizes that the culpability of a trader depends upon the conduct of 
the trader over time. Single trades rarely, if ever, give rise to the sort of culpability 
that would trigger a market manipulation case. Rather it is a series of events and 
a pattern of activity that might indicate a trader’s intent or whatever the level of 
culpability is required to prosecute a case. Similarly, the code of an algorithm rarely 
if ever would prove the sort of culpability necessary to prove a market manipulation 
case. Many perfectly legitimate algorithms that are typically used to advance inno- 
cent trading strategies might also be used nefariously by bad actors. For example, 
TT and, I believe, all ISVs in the futures industry have functionality in their trading 
systems that would stop a trader from executing a trade with himself. TT’s unimagi- 
native name for this feature is “avoid orders that cross.” Trading with oneself is pro- 
hibited on most exchanges, so this sort of functionality is mandatory for most of TT’s 
customers. However, I understand that some alleged bad actors may have utilized 
this functionality to manipulate markets. The alleged facts in these cases are that 
a large order is entered on one side of the market and then another entered to cross 
the first order. The first order would be pulled from the market and the second 
order would be entered. In this scenario, the alleged bad actor would have used an 
otherwise perfectly legitimate trading tool to move the market toward the first 
order, which was never intended to be filled. The functionality (i.e., algorithm) 
would not be helpful to prove manipulation in this case because, as mentioned 
above, there is a perfectly legitimate use for the functionality. Rather, only the al- 
leged bad actor’s behavior over time could establish culpability. 

Even in the unlikely scenario where the code of an algorithm might be helpful, 
the subpoena power of the Commission would be more than adequate to insure that 
the code is reviewed when truly necessary, although we continue to question when 
that would ever be the case. In fact, subpoenaing a written description of the intent 
of a trade or the basic algorithm that describes the strategy should be sufficient for 
most regulatory purposes. For example, a basic algorithm might be described as 
simply as “if market price = X then enter buy order at Y.” Such a simple description 
indicates the purpose of the algorithm much more clearly and easily than the vast 
expanse of source code that might otherwise be required under Regulation AT. 

It is worth noting that over the 17 years that I have worked at TT we have been 
contacted regularly by exchanges and governmental agencies like the CFTC and 
DOJ who are investigating trading manipulation and other cases. We are fortunate 
enough to have a large customer base that depends upon TT software every day for 
their livelihood. Unfortunately sometimes our customers are accused of violating 
regulations or rules while trading with TT software. As a result, we are asked to 
help the exchanges and government agencies understand how TT software works so 
that they can better understand what a trader may have been doing. We always 
cooperate to the extent possible by providing verbal descriptions, written docu- 
mentation and tutorials where appropriate. We also receive subpoenas relating to 
these cases and, of course, comply by producing information as required. Interest- 
ingly, despite such regular interaction, we have never once been required to produce 
the source code of any of our products. I believe this is the case because source code 
is not a necessary or desirable piece of evidence that might be used to avoid market 
disruption or prove or disprove bad acts in the marketplace. 

(3) Section 1.81 Testing Requirements Should Be Limited to Testing Fin- 
ished Products 

The last issue that I want to address is the testing requirements set forth in Reg- 
ulation AT. TT believes that such testing should focus on the output of an Algo- 
rithmic Trading system or software rather than the source code underlying such 
systems or software, which would yield no material benefit. 

As proposed, source code underlying an Algorithmic Trading system would be sub- 
ject to substantial, highly prescriptive testing in advance of a system’s roll-out and 
continually afterwards. 

a. Only Testing of the Finished Product Is Relevant to Regulation AT 

Any software product provided by TT to any customer is always tested internally 
by TT and is also available for the customer’s testing. TT expects that each cus- 
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tomer performs appropriate testing prior to utilizing the software in production en- 
vironments, especially when the product is an algorithm that might he used for 
trading. In fact, TT offers testing environments that simulate market conditions to 
facilitate such testing. Such functional testing of a product is conducted to deter- 
mine whether the output is consistent with the intended purpose of the product. The 
intended purpose is typically described in documentation provided hy TT or any 
other developer of the product. 

An important distinction between the sort of testing that clients perform every 
day on their software products and the proposed language of Regulation AT seems 
to be that the proposed rules require a registered entity to test software code (see, 
1.81(a)(ii)) as opposed to the finished product that the entity developed or licensed. 
To the extent the entity licensed the product from a third party, the source code 
is never available for testing and TT sees no reason why the code should ever be 
required for testing. The reason why customers purchase turnkey software is to uti- 
lize the product as a whole; testing of components of the source code is not con- 
sistent with that motivation and doesn’t make achieving the goals of the CFTC any 
more likely. 

If TT products do not work as expected, TT’s customers demand changes to the 
products and if TT fails to address their concerns, TT risks losing the customer. In 
that way companies like TT are effectively “regulated” by the market for software 
and systems. 

We cannot envision any type of testing that would be appropriate with respect to 
the code itself. If a line by line test of the code to determine whether there are flaws 
in the way it was written is intended by Regulation AT, it is unclear how any such 
review would provide any more or better insight than a test of the product itself 
to see what the outputs are. 

Moreover, taking the extraordinary step of mandating testing or review of source 
code is potentially very damaging to the source code owner as indicated previously. 

To the extent third party code is at issue, third party code simply will not be 
made available to licensees. Neither TT nor any other commercial software vendor 
that facilitates algorithmic trading licenses source code to its customers and will not 
willingly do so. We believe, respectfully, that any attempt to mandate third party 
vendors to produce such code outside of existing legal procedures, such as issuing 
subpoenas, would be an unprecedented overreach of governmental power without 
any merit. 

Thank you very much for the opportunity to testify before you today. I am happy 
to address any questions you may have. 

Attachment 1 


March 15, 2016 

Via Electronic Submission 

Mr. Christopher J. Kirkpatrick, 

Secretary of the Commission, 

Commodity Futures Trading Commission, 

Washington, D.C. 

Rc: Proposed Rulemaking on Regulation Automated Trading (Regulation 
AT) 

Dear Mr. Kirkpatrick: 

On behalf of Trading Technologies International, Inc. (“TT”), I am submitting this 
letter to comment on the Proposed Rulemaking on Regulating Automated (Regula- 
tion AT), specifically with respect to the proposed definition of Direct Electronic Ac- 
cess and a requirement that AT Persons be required to maintain a source code re- 
pository. 

I. Background of TT 

TT is an independent software vendor with approximately 400 employees located 
in its Chicago headquarters as well as offices in most major financial centers 
throughout the world. TT licenses software trading solutions enabling TT’s cus- 
tomers to trade on 45 of the world’s major electronic exchanges and liquidity plat- 
forms. TT’s customer base includes the largest banks, commercial firms, hedge 
funds, proprietary trading firms and other professional traders. TT offers many so- 
phisticated software applications for its customers’ use such as its new software as 
a service “TT” platform, as well as its legacy applications such as X Trader® and 
X Trader® Pro, X Risk®, ADL®, Autotrader™, Autospreader® and exchange gate- 
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ways. TT also hosts its customer’s infrastructure at facilities co-located or closely sit- 
uated with exchange matching engine technology. 

II. Comments on the Proposed Rules 

A. New Defined Term: “Direet Electronie Access” 

TT believes that the definition of “Direct Electronic Access” (“DEA”) should be 
clarified to indicate that there is no DEA where the orders are routed to a Des- 
ignated Contract Market through the trading/order routing system of a member of 
a derivatives clearing organization (“DCO”) where the pre trade and other risk con- 
trols are controlled by such member, including when a third party maintains the 
physical location of the systems. 

As drafted, the proposed definition is unclear and does not provide sufficient guid- 
ance as to what “being routed through a separate person” that is a member of a 
DCO means. The definition of DEA, as drafted, may suggest that the order would 
also have to be routed through a system physically controlled by the DCO member, 
but such physical control has nothing to do with the goal of enhancing risk manage- 
ment of such orders. Control of the risk parameters is the relevant issue and the 
definition of DEA should be altered to make clear that where such control exists, 
there is no DEA. 

The manner by which TT offers access to its trading system is typical of inde- 
pendent software vendors in the futures industry and although the methods of soft- 
ware distribution are diverse, a futures commission merchant (“FCM”) has the abil- 
ity to fully control the risk management settings in every case.^ Currently TT offers 
its software and services in four distinct ways: 

(1) traditional on-site licensing; 

(2) hosted servers; 

(3) shared hosted servers; and 

(4) software as a service (“SaaS”). 

On-site licensing involves licensing software that the customer installs at its loca- 
tion. In this case the exchange gateway software that connects the software with 
the exchanges is installed on servers in a server closet at the customer’s location 
and the client side software, that generates the trading screen, would be installed 
on the traders’ workstations. 

The last three methods of distribution help many FCMs achieve significant cost 
savings by outsourcing order routing technology to third parties without compro- 
mising on their control of risk parameters. 

Where TT hosts the servers, TT effectively moves its customers’ server closets into 
a TT managed location. In this case TT oversees the installation of all server soft- 
ware and maintenance of the applicable data lines and network. 

The shared hosted environment is similar in that TT hosts the server software, 
but here end-users can easily clear trades through multiple brokers because the 
physical infrastructure is shared and the software enables such relationships. 

The last method is as a fully hosted software as a service offering. Here the soft- 
ware is installed on hosted equipment and the trader interface is Internet based so 
there is no software installation on the workstation other than minimal code used 
in the browser. 

In each of the last three examples (hosted, shared and SaaS) the servers on which 
the gateway software connects a trader to an exchange sit at a TT managed loca- 
tion — not at a location managed by an FCM. TT manages the technical aspects of 
the hardware, software and telecommunication connections while the FCM’s retain 
complete control over user set-up and risk management tools that are provided as 
part of the TT order entry systems. 

The current definition of DEA doesn’t appear to fully recognize the relationship 
with such third party providers and should be clarified to allow for these common 
situations. One suggestion for modifying the definition would be to add “(including 
through a system physically managed by a third party retained by such member to 
act on its behalf)” after the phrase “who is a member of a derivatives clearing orga- 
nization.” Such clarification would not diminish any FCMs ability to control risk and 
therefore the legitimate goal of the new regulation would still be achieved. 

As drafted, the definition of DEA will likely capture within the definition of “Floor 
Trader” many single traders, small trading groups and even larger companies like 
energy firms who hedge on futures exchanges, all of whom trade through FCMs and 
are often substantial liquidity providers. This will add layers of administrative com- 


^Some FCMs choose not to utilize XT’s risk controls and instead rely on exchange provided 
risk tools, but the FCM may always control risk through the TT system if it chooses to do so. 
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plexity to their businesses and require them to hire expensive compliance experts 
to their staffs. Yet, no further risk oversight would be achieved because an FCM’s 
oversight is already fully integrated into the available trading systems. The goals 
of the Commission will not be achieved and the cost of compliance for these individ- 
uals and small groups will often price them out of the market. 

B. Source Code Repository 

TT is concerned that the requirement under section § 1.81(a), that AT Persons 
“maintain a source code repository to manage source code access, persistence, copies 
of all code used in the production environment, and changes to such code” is unnec- 
essarily and extraordinarily broad, not likely to provide helpful information, likely 
constitutes an unconstitutional taking of individuals’ property and is generally un- 
necessary to achieve the goal of the proposed regulations. To be clear, TT strongly 
urges the Commission to remove this requirement from the proposed regulation. 

1. Source Code Is Highly Proprietary and Typically Not Made Available to Third- 
Parties 

Although it is unclear exactly what is meant by the term “source code” in the pro- 
posed regulations,^ TT assumes that the term source code generally means software 
expressed in a high-level language intended to be intelligible by humans. Except 
with respect to open source licensing arrangements, to our knowledge, source code 
is never licensed under any software license agreement offered by any software pro- 
vider including any independent software vendor in the futures or securities indus- 
tries or any software firm such as Microsoft or Google. The source code of any trad- 
ing firm or technology firm goes to the essence of the value of such companies. It 
is highly proprietary, trade secret information that could expose the fundamental 
aspects of a business that provide economic advantage over competitors. Making 
such valuable intellectual property readily available to the Commission is unneces- 
sary to fulfill the intent of the regulations. 

TT is very concerned that despite numerous protections for confidential informa- 
tion submitted to the CFTC, there are gaps in such protections as well as too many 
possibilities to escape the CFTC’s control through unintentional means such as 
third-party cyberattacks.® If trade secrets are compromised, the trade secret status 
would likely be lost along with a firm’s economic advantage over its competitors. 
Such an action would likely amount to an unlawful “taking.”® 

It is also worth noting that much of the relevant source code potentially used by 
AT Persons comes from third party software providers like TT and others such as 
Microsoft. TT offers multiple applications through which a trader could implement 
an algorithmic trading strategy. Yet, TT never licenses its source code and would 
not provide it to its customers in any circumstances. TT is not alone in this position. 
For example, many traders utilize commonly available tools such as Microsoft 
Excel® to implement their trading algorithms. They might develop the algorithm in 
Excel and connect Excel to a commercial trading application like TT. Based on the 
movement of the market and the algorithm, orders might be triggered as a result 
of actions implemented in Excel. TT has not contacted Microsoft, but we suspect 


2 TT believes this term needs to be clarified if the Commission insists on keeping this require- 
ment. The Commission should also clarify which source code is relevant. As written, it seems 
the Commission is looking for a wide array of code that would touch all aspects of a trading 
system. 

® Although TT appreciates that a party submitting information to the CFTC may request that 
the information be treated confidentially pursuant to the provisions of CFTC Rule 145.9, the 
Assistant Secretary has discretion to grant or deny requests from requestors of non-public infor- 
mation. Moreover, it is TT’s understanding that Congress, and other governmental authorities — 
both U.S. and non-U. S. — may also request non-public information, and a submitter of non-public 
information may not be advised of this request or outcome. Finally, despite the best protections 
by the CFTC, cyberattacks and other unauthorized intrusions, as well as the illegitimate actions 
of staff acting contrary to their legal requirements, could compromise the sanctity of non-public 
information submitted to the CFTC. 

'^The Uniform Trade Secrets Act (“UTSA”) defines a trade secret as: 

• information, including a formula, pattern, compilation, program, device, method, tech- 
nique, or process, 

• that derives independent economic value, actual or potential, from not being generally 
known to or readily ascertainable through appropriate means by other persons who might 
obtain economic value from its disclosure or use; and 

• is the subject of efforts that are reasonable under the circumstances to maintain its se 
crecy. 

®See, Ruckelshaus v. Monsanto Co., 467 U.S. 986 (1984). 
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that software companies like Microsoft would not be willing to divulge their source 
code either. 

2. Source Code Is Complicated and the Potentially Relevant Amount of Source Code 
Is Enormous 

Even if the Commission was able to overcome the legal impediments relating to 
forcing disclosure of trade secrets, it is doubtful that such information would readily 
be useful to the Commission. One engineer’s source code is rarely drafted in the 
same manner as another engineer’s and without proper documentation to help deci- 
pher the code it is often meaningless. Even with proper documentation it would 
often take insight from multiple engineers to decipher the intent of the code and 
documentation. 

The breadth of the relevant code might also be so expansive that it is hard to 
fathom how it would be compiled, stored or used effectively. Each layer of code is 
very relevant to how an algorithm might function. Additionally, any number of dif- 
ferent coding languages might be used in each application and at each layer of soft- 
ware. TT, alone, uses over 30 different coding languages. 

In the Excel example above. Excel interacts with TT software, which includes and 
interacts with multiple layers of applications and libraries, which interact with 
other layers of messaging software and other systems on down the line until the 
operating system is utilized. In order to recreate the intent of the algorithm through 
the source code, the Commission would need to compile the code in the same envi- 
ronment where it was set up, including the same version of each layer of code and 
the same version of the exchange’s software. Short of that, it would likely not work 
the same as it was intended or as it might have worked at a moment in time. The 
code behind each layer of production software changes often. New releases occur 
regularly (often monthly) plus smaller code patches are released in between. Assum- 
ing there will always be a time lag between trading activity and when an investiga- 
tion is started, the Commission would need to be able to recreate the exact version 
of code including revisions and interim patches of each layer of code that was in 
use at the point in time of the trade. Each layer of code interacts and depends on 
the other layers to work as planned. A single version of a single layer of such code 
could be millions of lines; a repository of all possible code versions going back in 
time for years would be much, much larger and impose an immeasurable burden 
on the industry. 

As an example, consider the following simple algorithm that is depicted in TT’s 
“Algo Design Lab” application: 
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The logic of this simple algorithm is as follows: (1) submit a limit order 
for the given instrument and quantity at a price equal to the bid; (2) when 
the bid price changes, re-price the order to be the same as the bid. 

The simple image above belies the complexity and enormous amount of source 
code that generates this image and effects the strategy. One can imagine the image 
above as a depiction of the highest level of code used to effect the strategy. The 
strategy itself would run on a server application in the TT environment but it would 
also touch and be dependent upon almost every part of the TT trading system. The 
way that the algorithm subscribes for prices, downloads contract information, and 
routes orders is specific to the way that the underlying components have imple- 
mented and exposed this functionality. So technically, one would need all of the TT 
system software in order to attempt to reproduce its behavior. Hundreds of applica- 
tions and libraries within the TT system itself are essential components and the 
source code would likely add up to millions of lines of code for the TT applications 
only. If the trader used Excel for the algorithm, the Microsoft code would also add 
millions of lines of code most likely. Add to that the many other third party applica- 
tions involved in the process for price feeds, analysis, messaging, the operating sys- 
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terns of the workstation and the servers among other layers of code and there would 
be an immeasurable morass of code that, in theory, would need to be stored and 
made available to the Commission. 

This is a very simple example. The complexity of this simple example is magnified 
dramatically in a more complex and realistic example, not to mention situations 
where multiple algorithms are in question. 

3. Market Data Adds Another Level of Complexity 

Similarly, without the exact same market data flowing through it, the myriad 
software applications interacting together may not work the same. Replicating the 
market data is likely a bigger problem than it seems because trading programs 
often coalesce data and how and when coalescing happens may vary from moment 
to moment depending on many factors such as network routers, firewalls, switches, 
server hardware, operating system, vendor software, coalescing and conflation fac- 
tors. Multiplying the complexity exponentially, the Commission would likely have to 
replicate market data at a particular moment from multiple markets, because trad- 
ing algorithms will typically use and analyze data from multiple related markets, 
for example, equities and/or stock options if trading stock index futures. So, even 
if the Commission could recreate the prices in a market precisely as they were dis- 
seminated by the exchanges or other relevant markets, the software would likely 
act differently on different occasions despite using the same market data. 

Consuming market data is like drinking from a fire hose. The basic process by 
which TT delivers market data to clients is as follows: 

1. TT receives a market data update from an exchange {e.g., bid price = 100). 

2. TT broadcasts the update to other servers in TT’s trading network. 

3. The TT system notifies the client application. 

4. TT receives another market data update {e.g., bid price = 101). If the client 
has finished processing the last update, the TT system notifies the client of 
the update. If not, the system waits — and then delivers it when they are 
ready. 

(i) While waiting, the TT system might receive thousands more updates. TT 
conflates this data, meaning it overwrites the values that will be delivered 
to them when appropriate. This is done because no one wants to receive 
“old” market data updates. 

(ii) The time it takes a client to process an update depends on a variety of fac- 
tors, including system load, network load and operating system scheduling. 
This makes it extremely difficult to determine the exact price update that 
the client might process to re-price the order. So even with access to iden- 
tical system software, intermediate network and server infrastructure and 
the algorithm, one would likely be unable to reproduce the exact behavior 
of an algorithm for most liquid markets. 

Even assuming, for the sake of argument, that the Commission could make heads 
or tails of the morass of relevant source code and the complexities of dealing with 
market data, there is no compelling need to gain access to the code because it adds 
very little to reduce the risks of algorithmic trading. The outcome of the trades are 
indisputable evidence of the actual outcome of an algorithm and are already avail- 
able to every exchange and the Commission in the form of the trade data (orders, 
fills, quotes sent to and matched at each exchange). Unusual results and/or repeated 
outcomes demonstrate the intent of traders and usually no more is necessary to es- 
tablish intent. Even where more is necessary, the subpoena power of the Commis- 
sion would be more than adequate to insure that the code is reviewed when truly 
necessary, although we continue to question when that would ever truly be nec- 
essary. In fact, subpoenaing a written description of the intent of a trade or the 
basic algorithm that describes the strategy should be enough without even delving 
into source code. This would amount to a document detailing the logic of the algo- 
rithm that would direct the trade (e.g., “if market price = X then enter buy order 
at Y.”) 

The extraordinary burdens described above, the potentially illegal or overly dam- 
aging intrusion into proprietary source code incurred by trading firms and their 
software suppliers and the questionable benefit of obtaining any further code far 
outweigh any benefit from acquiring the code. 

TT is very concerned that, as drafted. Regulation AT will not positively enhance 
the existing regulatory regime for automated trading. We addressed two aspects of 
the proposal about which independent software vendors like TT seem to have good 
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insight. We are more than willing to provide additional input about these matters 
or others matters within our expertise. 

Please contact me at (312) 476-1081 if you have any questions or seek additional 
information. 

Respectfully submitted, 

\\ -A 

Michael G. Ryan, 

Executive Vice President and General Counsel. 

Attachment 2 


June 26, 2016 

Via Electronic Submission 

Mr. Christopher J. Kirkpatrick, 

Secretary of the Commission, 

Commodity Futures Trading Commission, 

Washington, D.C. 

Rc: Proposed Rulemaking on Regulation Automated Trading (Regulation 
AT) 

Dear Mr. Kirkpatrick: 

I am submitting this letter on behalf of Trading Technologies International, Inc. 
(“TT”), to respond to certain issues raised during the June 10, 2016 public round- 
table discussion regarding Regulation AT. Specifically, TT would like to address pro- 
posed testing requirements for Algorithmic Trading (as defined in Regulation AT) 
systems and software. 

Section 1.81 Testing Requirements Should Be Limited to Testing Finished 
Products 

TT applauds all reasonable regulatory initiatives to ensure that market integrity 
is enhanced through testing of Algorithmic Trading systems and software. TT be- 
lieves that Section 1.81(a) of Regulation AT, which would impose certain develop- 
ment and testing requirements for Algorithmic Trading systems, should be clarified 
so that it can be implemented in the most practical and useful manner. TT believes 
that such testing should focus on the output of an Algorithmic Trading system or 
software rather than the source code underlying such systems or software, which 
would yield no material benefit. 

TT Performs Regular Tests on the Software It Licenses 

As a third party software vendor, TT’s view of the proposed rules may be different 
than entities that are directly regulated by the Commodity Futures Trading Com- 
mission (“CFTC”). TT practices commonly accepted development and testing prac- 
tices and only licenses systems and software that have been subject to a rigorous 
testing protocol. This protocol includes: 

• testing in a development environment separate from a production environment; 

• back testing and stress testing; 

• documenting the specifications and requirements of source code; and 

• retaining of source code in an environment where changes are recorded. 

TT’s practices are consistent with the requirements the CFTC proposes to be 
adopted by AT Persons. In fact, other independent software vendors in the futures 
world, and most likely all companies that license software and systems, such as 
Microsoft, Adobe, Google, etc., already follow those practices every day in an effort 
to produce software and systems that perform as intended. 

Only Testing of the Finished Product Is Relevant to Regulation AT 

As TT indicated in its previous comment letter and during the roundtable discus- 
sion on Regulation AT, in no event does TT or any software vendor in any industry 
provide access to source code as part of its license grant to its customers.^ But, any 
software product provided by TT to any customer is always available for the cus- 
tomer’s testing and TT expects that each customer performs appropriate testing 
prior to utilizing the software in production environments. In fact, TT offers testing 


^ The exception to this statement would be vendors who license open source software. 
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environments that simulate market conditions to facilitate such testing. Such func- 
tional testing of a product is conducted to determine whether the output is con- 
sistent with the intended purpose of the product. The intended purpose is typically 
described in documentation provided by the developer of the product. 

If TT products do not work as expected, TT’s customers demand changes to the 
products and if TT fails to address their concerns, TT risks losing the customer. In 
that way, companies like TT are “regulated” by the market for software and sys- 
tems. 

An important distinction between the sort of testing that clients perform every 
day on their third party software products and the proposed language of Regulation 
AT seems to be that the proposed rules require a registered entity to test software 
code (see, 1.81(a)(ii)) as opposed to the finished product that the entity licensed. To 
the extent the entity licensed the product from a third party, the code is never avail- 
able for testing and TT sees no reason why the code should ever be required for 
testing. The reason why customers purchase turnkey software is to utilize the prod- 
uct as a whole; testing of components of the source code is not consistent with that 
motivation and doesn’t make achieving the goals of the CFTC any more likely. 

We cannot envision any type of testing that would be appropriate with respect to 
the code itself. If a line by line test of the code to determine whether there are flaws 
in the way it was written is intended by Regulation AT, it is unclear how any such 
review would provide any more or better insight than a test of the product itself 
to see what the outputs are. 

Moreover, taking the extraordinary step of mandating testing or review of source 
code is potentially very damaging to the source code owner as indicated in TT’s prior 
comment letter, several other comment letters and verbal comments to the CFTC. 

To the extent third party code is at issue, third party code simply will not be 
made available to licensees. Neither TT nor any other commercial software vendor 
that facilitates algorithmic trading, such as Microsoft through its products like 
Excel®,^ licenses source code to its customers and will not willingly do so.® We be- 
lieve, respectfully, that any attempt to mandate third party vendors to produce such 
code outside of existing legal procedures, such as issuing subpoenas, would be an 
unprecedented overreach of governmental power without any merit. 

Whether a Product Is Licensed from a Third-Party Does Not Change the 
Appropriate Testing Procedures 

Some have argued that, absent a requirement by the CFTC, an FCM or other reg- 
ulated entity would have no control over how third party code might be tested, mon- 
itored or altered to address issues that may arise in an algorithmic trading environ- 
ments. When looked at from a practical perspective, such an objection has no merit. 

If an FCM was to test an algorithmic trading system it would run the algorithm 
in a simulated environment to determine what the outputs of the system would be 
under various market scenarios. If a problem was detected by a tester or compliance 
specialist, that person would turn off the algorithm,"^ contact the developer of the 
algorithm, point out the problem and ask the developer to fix the problem. The de- 
veloper would then review the code that implemented the algorithm and make any 
appropriate adjustments. Then the algorithm would be retested in the simulation 
environment and the process might repeat itself until the algorithm was determined 
to be running as planned. The process would be the same if the problem was discov- 
ered in a production environment — the algorithm would be turned off and it would 
be fixed by the developer and then tested in a simulation environment before being 
used again in a production environment. If the algorithm had been developed in- 
house at an FCM that developer might sit down the hall from the tester or the com- 
pliance specialist. If the algorithm was developed by a third party, the developer 
would be a phone call away. The testing would be the same and tbe resolution of 
any issues would be the same. 

TT, respectfully, remains very concerned that, as drafted. Regulation AT will not 
positively enhance the existing regulatory regime for automated trading. We appre- 
ciate the opportunities afforded to us to comment on Regulation AT and are more 
than willing to provide additional input about these matters or others matters with- 
in our expertise. 


2 Excel is a registered trademark of Microsoft Corporation. 

® As indicated in TT’s original comment letter, TT has not been in contact with Microsoft, but 
we would suspect that commercial software companies like Microsoft would not be willing to 
divulge their source code. 

Mandating such a kill switch seems prudent. 
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Please contact me at (312) 476-1081 if you have any questions or seek additional 
information. 

Respectfully submitted, 

Michael G. Ryan, 

Executive Vice President and General Counsel. 

The Chairman. I want to thank our witnesses. 

The chair would remind Members they will be recognized for 
questioning in order of seniority for the Members who were here 
at the start of the hearing. After that, Members will be recognized 
in order of arrival. I appreciate Members’ understanding. 

And with that, I will recognize myself for 5 minutes. 

Mr. Wood, under the broad definitions provided in Reg AT, and 
the ubiquitous use of automated trading in the market, what per- 
cent of market participants do you think would qualify as AT per- 
sons? 

Mr. Wood. Thank you for the question, Mr. Chairman. We have 
seen an adoption of automated trading in the futures markets that 
has become prevalent in many ways. Reg AT has tended to focus 
on a particular type of participant. The argument that FIA has 
made is automated trading is used by a lot of different types of 
market participants in one form or another. There are people who 
use highly sophisticated systems that they develop themselves, but 
there are people who also increasingly use systems that are pro- 
vided by software vendors or by the FCM community for them to 
execute more efficiently within the futures markets. 

So trying to quantify how much of the market is truly algo- 
rithmic in nature, it is going to actually be a very high percentage. 
And I would actually defer to Andrew Vrabel here, because they 
use metrics on their orders going into the CME Globex platform 
that actually highlights whether an order is manually generated or 
automated. 

The Chairman. Mr. Vrabel, do you have that number off the top 
of your head? 

Mr. Vrabel. The number off the top of my head is that, in our 
agricultural markets, roughly 50 to 53 percent of total volume 
comes from automated strategies. And as I had mentioned before, 
every type of market participant, not every participant but every 
type of participant uses some form of automated trading strategy 
or another, whether it be, as Greg said, a highly complicated algo- 
rithm or a simple auto spreader available through any ISV or soft- 
ware contractor. 

The Chairman. Mr. Gorelick, some would argue that the CFTC 
should use Reg AT to involve itself in the inner workings of algo- 
rithmic trading systems to anticipate problems. Is it remotely pos- 
sible that the CFTC would be able to anticipate problems in the 
market by studying source code? 

Mr. Gorelick. I would say it is highly implausible. I was trying 
to think of an analogy that would help to sort of explain what this 
test would be, and it is tricky for a variety of reasons but, the best 
I can come up with, it is sort of like taking a car apart, and taking 
all the pieces and studying them in excruciating detail to try and 
predict traffic patterns. It is sort of relevant, if you want to figure 
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out how to build a car it is very useful, but it is not the best way 
to measure traffic patterns. What you really need to do is go out 
there and measure. And that is what we are trying to do. By look- 
ing at source code, with millions of lines, with lots of interactions 
that are very dependent on the specific market data that is coming 
in at a particular time, that is very dependent on the hardware 
that it is running on, the network characteristics, it would be very 
difficult to determine future market events by studying source 
code. 

The Chairman. Let me ask you, some of you mentioned this two- 
tiered level of pre-trade risk controls. Are there barriers to those 
being implemented now on a voluntary basis? Mr. Vrabel, is that 
scheme already in place, the two-tier that you talked about? 

Mr. Vrabel. Yes, the scheme is largely already in place. The ex- 
changes have comprehensive market integrity controls that have 
been in place for years. By and large, every market participant has 
some degree of risk controls. 

The real question under Reg AT is whether those risk controls 
are adequate, given the scope and scale of that particular algo- 
rithmic trader. But yes, in our experience, I have not encountered 
a firm that has zero risk controls in place. 

The Chairman. Well, I am talking about that two-tiered system 
that you have mentioned where, obviously, the trader should have 
controls in place, the FCM should have controls in place, the DCM 
should have controls, is there something preventing the SROs from 
actually requiring that to be in place already? 

Mr. Vrabel. There is not, and the two-tiered model is what we 
have offered instead of a more complicated structure, for example, 
portions of Reg AT lead one to believe that there could be as many 
as three tiers. The exchange has to have an appropriate level, the 
clearing firm has to have a level of protection, and the algorithmic 
trader has to have a level of protection. And, redundant measures 
like that we not believe are 

The Chairman. Okay. The Ranking Member mentioned 15 to 30 
issues a year in which that happened. Are those numbers going up 
or down as a result of the array of controls that self-imposed has 
had? Is that getting better or worse? 

Mr. Vrabel. My understanding of that 15 to 30, or 15 to 20 num- 
ber, wasn’t an analysis of the number of malfunctions that have 
caused a market disruption. Instead, it was based on a calculation 
of markets that have had price swings of a certain degree over a 
period of time. One important thing to note is that the preamble 
to Reg AT notes significant market events resulting from algo- 
rithmic trading, and the only one in CFTC-regulated markets is the 
May 6, 2010, flash crash that the CFTC addresses there. And since 
that point in time, there have been 12 billion trades on CME’s mar- 
kets. 

Now, obviously, we have had other small events, but the risk 
protections that are in place we believe are adequate, and have 
been adequate to address those. 

The Chairman. Yes. Thank you. 

The Ranking Member, 5 minutes. 

Mr. Peterson. Thank you, Mr. Chairman. 
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Does the Division of Market Oversight have subpoena authority? 
Does anybody know? 

Mr. Wood. I believe the Division of Enforcement at the CFTC 
does. 

Mr. Peterson. The Enforcement Division has subpoena power? 

Mr. Wood. Yes. 

Mr. Peterson. Is there a Division of Market Oversight? 

Mr. Wood. I believe in this circumstance, the various divisions 
at the CFTC would work together if they needed to take this course 
of action. 

Mr. Peterson. I guess, as with a lot of the stuff that we found 
out as we went through all of this that until you get into enforce- 
ment, sometimes you can’t find out anything about what is going 
on with these things, unless you get into an enforcement situation. 
Is that right? 

Mr. Wood. I believe so, yes. 

Mr. Gorelick. Ranking Member Peterson, that is a good ques- 
tion. What I have suggested is that the best way to figure out what 
is going on with an algorithm or with a particular trading strategy 
is to really look at the data, at the orders and the fills and the can- 
cellations, and all of the audit trail information that is readily 
available to the exchanges and to the CFTC. That is going to give 
you a much better idea of what is going on with the trading strat- 
egy than sort of a preemptive, extraordinary code review. 

Mr. Peterson. Well, can they get that information? 

Mr. Gorelick. Absolutely. I think that is where ongoing invest- 
ment is warranted. Right now, one of the great advantages of elec- 
tronic trading and of the electronification of our markets has been 
that there is now a complete audit trail available of every message 
that is sent back and forth from the exchange by traders and ev- 
erywhere else. And that allows sort of an unprecedented level of 
transparency into what is going on in the markets. Regulators need 
to continue to develop their skills and their technologies and their 
toolsets to conduct that analysis, but right now the exchanges al- 
ready have terrific surveillance capability built on these audit 
trails, and the CFTC has an opportunity to piggyback on that as 
well. 

Mr. Peterson. Yes. So they don’t have enough resources to do 
as much of this as they should, is that 

Mr. Gorelick. Yes, I am not sure, this is something that has 
come up at the Technology Advisory Committee over the years. I 
think that is really more of an issue for Congress and for the CFTC 
to talk about resource-wise. I certainly think that it is an area of 
focus to make sure that they are investing appropriately in both 
their technology and in their analytical capabilities. I think that is 
going to be a much better, more efficient investment than in source 
code review capabilities. 

Mr. Peterson. Are they doing that? 

Mr. Gorelick. I believe they are, yes. Whether it is enough, 
whether it is sufficient, whether they could do it better I am not 
positive about. 

Mr. Peterson. Yes, with a lot of these different issues, it seems 
like people get more tied up in all the enforcement stuff and they 
miss the trees for the forest. When I was on the Intelligence Com- 



40 


mittee, I had a similar issue with the FBI, who were not doing 
what they should be doing, because they were more worried about 
enforcement than they were trying to figure out what was going on. 
Do you think that the CFTC has figured this out and is moving in 
the right direction? 

Mr. Gorelick. I would say that they are moving in the right di- 
rection. This has clearly been an area of focus and a lot of discus- 
sion at the Technology Advisory Committee. I do think though that 
this is an area that probably needs more focus. It would be a more 
fruitful avenue to pursue than the source code provisions in Reg 
AT. 

Mr. Peterson. Yes, sir. 

Mr. Ryan. If I may add something. One thing that I want to note 
is that I have been at TT for about 17 years, and we often get con- 
tacted by the CFTC, sometimes the Department of Justice in an 
enforcement action and the like, and asked questions about our 
technology. The questions are how does it work, can you give us 
some documentation to explain how it works in this scenario or 
that scenario. And we are always there to answer those questions. 
We are always happy to do that. But never once in my 17 years 
at TT have we ever been required to provide source code. 

So it just seems to me, the source code avenue is an avenue that 
is not likely to help in this analysis. 

Mr. Peterson. Well, Mr. Chairman, maybe the Committee 
should look into that and find out more about it. 

The Chairman. Well, I do think the proprietary source code, the 
property-taking under the Constitution, they are troubling that 
they can simply request that. It is apparently on everybody’s mind. 

Do you yield back? 

Mr. Peterson. Yes. 

The Chairman. The gentleman yields back. 

Mr. Goodlatte, 5 minutes. 

Mr. Goodlatte. Mr. Chairman, thank you for holding this im- 
portant hearing. And thank you to the panel for being with us 
today. 

While there may be a number of significant concerns with this 
rule, I would like to zero-in on one particular aspect that has been 
mentioned several times already today in this issue of source code 
repository. 

It seems that through this rule, the CFTC has decided to use its 
legitimate authority to access books and records as a means to ille- 
gitimately force trading companies to turn over valuable intellec- 
tual property without first obtaining a subpoena. And I am dis- 
turbed by this decision and, therefore, I have a few questions for 
the panel. 

First, how difficult is it currently for the CFTC to obtain a sub- 
poena for a source code, and who at the CFTC can authorize that 
type of action? Anybody answer that? None of you know? 

Mr. Vrabel. 

Mr. Vrabel. I am by no means an expert on the administrative 
procedures, but my understanding is that an administrative sub- 
poena has to be approved by all Commissioners. 
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Mr. Goodlatte. All the Commissioners, right. But nonetheless, 
if they have a desire to subpoena documents from any of the com- 
panies that are affected by this, they have the ability to do that. 

Second, how will this type of unfettered access to source code be 
beneficial to the CFTC? Would this reduce risk to the system, or 
does CFTC currently retain staff able to easily understand and in- 
terpret the code? Mr. Gorelick, you have commented on this a bit 
already. Could you elaborate on that? 

Mr. Gorelick. I did. No, I don’t think the CFTC has the capa- 
bility to routinely evaluate large amounts of source code. The soft- 
ware programs are written in lots of different programming lan- 
guages, they are very extensive, they are often — really the best way 
to understand exactly the inner workings is to talk to the software 
developers involved in writing that code. 

As I referenced, I think it would take an army of software devel- 
oper regulators, and I am pretty sure that the CFTC does not pres- 
ently have that capability. 

On a one-off basis in connection with an enforcement action with 
a very narrow set of actions, it may be useful. And I am not aware 
of any circumstances in which the CFTC thought they needed 
source code for that purpose and were unable to get a subpoena. 
What we are really talking about is a due process concern. The 
times in which the CFTC would need to access source code, they 
can get a subpoena, they can use the subpoena process, and there 
will be adequate protections built in. 

Mr. Goodlatte. We are also talking about a security concern 
here, aren’t we? I mean isn’t this something similar to the Apple- 
FBI dispute where the FBI wanted to compel Apple to unlock 
something? Here, they are asking for the authority to have auto- 
matic access to it, and once they have automatic access to your 
source code, what are the risks involved that it will fall into the 
wrong hands; either a competitor or a criminal, or even a foreign 
government that might use it to manipulate the market? 

Mr. Gorelick. Firms like ours, firms that use automation in the 
markets, generally hold their source code to be very important to 
their business. They take their own precautions to protect their 
source code. They store it in secure ways, they secure their net- 
work, they have the cybersecurity defenses, they have authority 
about who is allowed to access it and under what circumstances. 
Once it is out of a particular firm and in the hands of sort of any 
third party, the firm loses the ability to manage those controls. And 
as we have seen, there is risk that if the information is attacked 
by third parties in some type of a cybersecurity attack, or simply 
that information gets out there. People change jobs, it moves from 
one place to another, and it could really have a negative impact 
from a competitive standpoint. So generally, the issue is who is 
able to have the types of controls that are required. 

Mr. Goodlatte. Right, and it exponentially could increase the 
vulnerability of that source code to discovery by individuals who 
shouldn’t have access to it. You have to worry about yourself Busi- 
nesses are hacked all the time. 

Mr. Gorelick. Right. 

Mr. Goodlatte. Government agencies, retailers, credit card com- 
panies, the list goes on and on of people who have had important 
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information hacked, including, in some instances, their very source 
codes. So if this is in the hands of a government agency, that 
wouldn’t inspire your confidence that your vital piece of how your 
business operates will he better protected. It will be more vulner- 
able, will it not? 

Mr. Gorelick. I think that is the case whenever it is outside of 
our hands. A government agency would just be like any other third 
party from that regard that we don’t control who is able to look at 
this information, how they are able to get it, what security they 
have put in place. We only like to have a very small group of peo- 
ple inside our firm who are responsible for those controls, and not 
more broadly open access. 

Mr. Goodlatte. Thank you very much. 

Thank you, Mr. Chairman. 

The Chairman. The gentleman yields back. 

Mr. Scott, 5 minutes. 

Mr. David Scott of Georgia. Thank you, Mr. Chairman. 

I certainly applaud the CFTC’s overarching efforts to bring the 
futures markets’ regulatory regime into the 21st century. And as 
a matter of fact, it was almost a year ago to the day, in July 2015, 
that the Chicago Mercantile Exchange, CME, shuttered the last of 
its trading pits after 167 years of operation. So it makes a great 
deal of sense that the CFTC move on these rules now that trading 
pits are officially a thing of the past. However, when I heard that 
the CFTC would require people affected by this rule to not only re- 
tain all copies of their source code, but also make it available to 
the CFTC at their demand, without a subpoena. It caused me great 
alarm. 

So I wanted to first ask the panelists if each of you drew the 
same conclusion that I have, in that the Reg AT being unprece- 
dented, and that it could demand source code without a subpoena. 
Everybody agree? 

Mr. Ryan. Yes, I will address that first, if I may. Congressman. 

From our perspective, TT and the others in the industry are al- 
ways willing and able to help with useful information, when that 
useful information is available. The biggest concern, in addition to 
the security aspect of handing over the source code, is that it is un- 
likely that in any scenario it is actually going to be useful. I gave 
an example on one of the comment letters that I issued to the 
CFTC that had an image of a very simple algorithm. It was just 
an image where you entered an order at the best bid on the mar- 
ket, and if it moved, you went with it. It is an image that is maybe 
about this big. 

Mr. David Scott of Georgia. Yes. 

Mr. Ryan. Okay. The amount of code that goes into generating 
that image and then executing the order that that image tries to 
put into place is incredibly expansive. I mean we are talking like 
millions of lines of code, ultimately, to effect that simple of a proc- 
ess. 

Mr. David Scott of Georgia. And let me get rather specific here 
for a moment. And, Mr. Vrabel and Mr. Gorelick, you touched on 
some of this, but do you think that the CFTC should have a defini- 
tion of automated trading that separates out automated execution 
from algorithmic strategies that drive trading decisions? My worry 
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stems from the CFTC forcing automated traders to share their al- 
gorithmic strategies or secret recipes with the CFTC, whenever the 
CFTC wants it. Now, couldn’t a better solution to this problem be 
that if the CFTC separated out those two definitions, we could bet- 
ter protect these secret recipes? 

Mr. Vrabel. Respectfully, Congressman, I don’t know if that will 
adequately address the issues. In my experience when our teams 
have reviewed and monitored disruptions in the markets resulting 
from automated trading, algorithmic trading, or simple devices like 
order routers, we see as many malfunctions that cause disruptions 
in the markets from very simple devices as we do from highly com- 
plex ones. 

Mr. David Scott of Georgia. Yes. 

Mr. Vrabel. So from my perspective, if there is going to be risk 
controls that are addressing automated trading, it would need to 
include the algorithmic, highly complex, and the very simple order 
routing automated strategies. 

Mr. David Scott of Georgia. All right, and determining the 
boundaries of a particular group of market participants is always 
a problem when trying to define the scope of regulation. I serve on 
the Financial Services Committee, and we have that problem all 
the time. But oftentimes we deal with this problem by regulating 
the activity that is being done, as opposed to regulating the entity 
that does it. 

I wonder if we are encountering a similar type of problem here 
with the definition of the AT person. Is the scope of this regulation 
exhaustive, are the lines we are drawing with this AT person defi- 
nition too big, is it too small, and could a better way be to regulate 
the activity that the AT person is doing as opposed to regulating 
the entity? 

Mr. Wood. Congressman, if I can take that one. FIA has cer- 
tainly always advocated that there shouldn’t be a very strict defini- 
tion of who is an AT person, because the lines have increasingly be- 
come blurred between automated and algorithmic trading to the 
point that it becomes meaningless in the sense of the interaction 
with the marketplace. And to your point, we have stressed to the 
Commission that they should be looking more at the what, the ac- 
tual activity, the automated nature of the activity in the U.S. fu- 
tures markets, as opposed to trying to look at the who, and trying 
to create some sort of arbitrary categorization where people either 
fit into that category or outside of that category, which really 
doesn’t do anything to protect the overall integrity of the market- 
place. 

Mr. David Scott of Georgia. Okay. Thank you, sir. 

Thank you, Mr. Chairman. 

The Chairman. The gentleman yields back. 

Mr. Lucas, 5 minutes. 

Mr. Lucas. Thank you, Mr. Chairman. And thank you to the 
panel for being here today. 

A big part of what we do is establish a base of information and 
knowledge, in these Committee hearings. So just go back to the 
fundamentals for just a moment, and I would say, Mr. Woods or 
Mr. Gorelick, or whoever would like to answer this question, ex- 
plain to us for just a moment what the benefits of automated trad- 
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ing provide to the participants, that fundamental question about 
why this matters. Surely it benefits someone or we wouldn’t be 
doing it, right? 

Mr. Gorelick. Absolutely. If you look back at the development 
of the markets over the last 15, 20 years, as markets have become 
more electronic, market participants have started to automate a lot 
of the functions that they did previously. So in terms of evaluating 
market data and what is going on, in terms of placing orders, in 
terms of adjusting orders, in terms of managing risk, all of those 
functions are, in many ways, better handled by a computer much 
more efficiently than they were able to be handled previously. And 
the result of all of that is that costs for end-users in the markets 
have come down. And if you look at the data, sort of end-user costs 
in a variety of markets that have become increasingly electronic, 
increasingly automated, and in turn, increasingly competitive, the 
result is that the costs to the end-user are much lower. And that 
is the primary benefit of automation. 

Mr. Lucas. Increased efficiency of the process. Absolutely. 

Mr. Ryan, in Reg AT it doesn’t appear to provide a real definition 
of what source code is. Is there some universal definition that 
CFTC and other entities like to use? 

Mr. Ryan. Yes. 

Mr. Lucas. Because we have come a long ways in my 40 years 
from playing with COBOL and FORTRAN in those freshman class- 
es back in the 1970s. 

Mr. Ryan. Sure. I don’t think that the general definition of 
source code, first, I don’t think it is really defined in the proposed 
regulation, but I don’t think that is too controversial a concept. Ba- 
sically, it is a high-level software language that is supposed to be 
written in a way that is intelligible to humans. So it is not the ma- 
chine language, it is not binary code. The part that is more con- 
cerning is the breadth of the source code that is being requested 
under the regulations. 

Mr. Lucas. One last question. Mention was made about not just 
proprietary code developed by a firm, but vendors being available 
to purchase this from. For curiosity’s sake, how much of an indus- 
try is this, do we have dozens or hundreds of vendors who have 
these products for sale, retail? 

Mr. Ryan. Well, we have 

Mr. Lucas. And I address that to anyone who would care to re- 
spond. 

Mr. Ryan. Sure. I mean, actually, others might know it better 
than I do, but we have many. I mean I would say in the futures 
worlds, maybe a dozen or more, or dozens, I guess, vendors that 
are available. 

Mr. Wood. Yes, I would add from an FCM perspective where we 
provide access to our customers, we see many firms who either 
write their own code or are using third parties, or they are even 
using algorithmic trading software provided by ourselves. And in 
terms of numbers, there are, yes, certainly many different types of 
firms that provide different levels of type of automation. 

Mr. Lucas. And with the resources involved and the sophistica- 
tion of the users, I would assume this is an incredibly competitive 
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process developing this software for sale, and I can just imagine 
how competitive. 

With that, Mr. Chairman, I yield back. 

The Chairman. The gentleman yields back. 

Ms. DelBene, 5 minutes. 

Ms. DelBene. Thank you, Mr. Chairman. And thanks to all of 
you for spending time with us this morning. 

Everyone has brought up the issue of source code and concerns 
about unfettered access to source code, and not maintaining a sub- 
poena standard. Mr. Ryan, brought up the issue of kind of the ac- 
cess of code with actual data flows coming in. And when you are 
doing testing and there are obviously the requirements on testing 
within the regulation, can you talk about how you develop code and 
how you test it, test your source with data so that you can under- 
stand how it is working? 

Mr. Ryan. To a degree, I can talk about that. I am the lawyer, 
I am not the technologist. 

But yes, throughout the development cycle we test the data to 
look at things like how it is working functionally, whether there 
are security issues involved with it, whether the code is written ap- 
propriately, how it works in relation to the market itself. An issue 
that I have raised on this is that I question whether that review 
of code is really the relevant test, as opposed to the review of the 
output of the product because it is that output that is really what 
is relevant to an analysis of whether there is a problem, at the end 
of the day. 

Ms. DelBene. Do others have feedback on how you test and how 
you combine those two together to one, see if you are getting the 
results that you want in terms of creating the product that you 
thought you were creating? 

Mr. Gorelick. Well, that is a very important point that the soft- 
ware in and of itself won’t tell you very much about what is going 
to happen in the market. It is really an issue of seeing how the 
software runs in a live market. 

Now, what we do internally is lots of different kinds of testing. 
We do component-level testing where we look at a particular piece 
of code and develop test cases around that to make sure it is func- 
tionally the way we intend. We do system-level testing where we 
actually dummy-up information sources so that the information 
comes, in a way that is as close to what we expect to see in the 
real market as we can. And then we do live-market testing where 
we actually trade these markets, after they have passed all of our 
other tests, at small scale in the market to make sure that they 
do what we expect them to do, based on all of our testing. 

There is extensive testing that goes on. The real core of the issue 
is though, from a software standpoint, is looking at the software 
close to enough to let you know how it is going to operate in the 
real live market, and when you are not taking into account all the 
data, the timing issues, the hardware issues, the network issues, 
it is hard to get comfortable that there will be a lot of insight 
gained from that. 

Ms. DelBene. Yes. 

Mr. Wood. And if I can just add to that. Source code is the basis 
for when something is actually running in production. There are a 
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lot of runtime parameters; i.e., real-time inputs, that come not just 
from the people who are using the software, hut also from the mar- 
ket itself. And these are factors that, obviously, influence how the 
software then interacts with the market. Generally, across the in- 
dustry, we have been trying to say the only way that you can try 
and control this is to ensure there are appropriate pre-trade risk 
controls in place to mitigate the possibility that something may go 
wrong, or something may occur that could disrupt trading in the 
marketplace. 

Ms. DelBene. All of you are saying if you aren’t really studying 
the overall environment, just looking at code and looking at the 
lines of code, you are not necessarily going to have the insight you 
would have unless you saw the entire environment, which is the 
data flowing through the system and the output of the system, 
which I guess speaks to the point that you made, Mr. Gorelick, ear- 
lier about the resources that would be required there. 

Secondarily, then there is the protection, the protection of source 
code and trade secrets and IP, and does anyone have any problems 
with the way things have worked to date in terms of having the 
subpoena standard that has been in place? 

Mr. Wood. One thing I would just say to that is it usually takes 
several steps before it gets to a subpoena level. Working for an 
FCM, we often get inquiries from both the SROs and from the 
CFTC for a section 4g inquiry where they are asking for informa- 
tion. And, of course, we will try our best to provide that informa- 
tion. We will talk to our customers if it involves their customers, 
if they are direct members of the SRO, obviously, they would be di- 
rectly approached. So we would go through all appropriate steps to 
provide as much information and background before we got to the 
subpoena process. 

Ms. DelBene. Thank you so much. 

My time has expired. I yield back, Mr. Chairman. 

The Chairman. The gentlelady yields back. 

Mr. King, 5 minutes. 

Mr. King. Thank you, Mr. Chairman. And I thank the witnesses 
for your testimony. 

I turn first to Mr. Gorelick, and I pose a question this way. All 
the things we are talking about here with algorithmic trading, 
could you paint for us, since you have been really good metaphori- 
cally so far, worst case scenario, if we did nothing and let this 
thing just race where would it go, what would be the worst case 
scenario? 

Mr. Gorelick. Markets certainly have experienced disruption, 
and there has been manipulation. There has really never been a 
market in the history that has not had some kind of problems with 
it, and some of those problems have come forward as the markets 
have been electronified and automated. 

My sense is that there are a lot of safeguards that the industry 
has already put in place to really mitigate the risk of the worst 
case scenarios that we are talking about; markets spinning out of 
control in some way, that there are multiple layers of risk controls, 
there are best practices that have been discussed widely, there are 
audit functions from the exchanges, there are lots of things that 
have gone on over the years to help create and innovate multiple 



47 


layers of risk controls to help keep the market in line, and by and 
large, they work extremely well. Our job here today is to think 
about those worst case scenarios, and think about the events in 
which in which things have gone wrong, but it is important to note 
that almost all day, every day, markets trade and function ex- 
tremely well. 

So my sense is that, generally speaking, the worst case scenarios 
are largely mitigated, but we need to keep after it. We need to im- 
prove our data analysis skills from the regulatory standpoint, we 
need to continue to invest in technology, and we need to continue 
to develop best practices in a flexible regulatory environment. 

Mr. King. I tend to agree with you about the corrections that 
would take place along the way, but what about worst case? 

Mr. Gorelick. Right. I think the worst case 

Mr. King. How would that come about? 

Mr. Gorelick. Yes, sure. What we are all worried about is mar- 
ket disruption such as the flash crash where the market went down 
very quickly and then recovered very quickly, without a lot seem- 
ing to happen to explain that quick turnaround. 

Mr. King. Okay, let me dial this back to the 2007 or 2008, the 
broader financial market near-collapse that we had, and the inven- 
tion of the concept of too big to be allowed to fail. And if I recall, 
the insurance component of that was AIG, who went clear to the 
bottom. But there were people buying that on the way down, or 
there wouldn’t have been a market, and those folks that bought it 
all the way to the bottom made a lot of money coming back the 
other way. So I might paint that as a worst case scenario with re- 
gard to those markets. Is there a similar scenario that you could 
paint with regard to the algorithmic trading? 

Mr. Gorelick. Yes, that would be the concern, again, that mar- 
ket prices don’t reflect real market realities. And typically speak- 
ing, there are so many firms looking at these markets and trading 
for those opportunities that, if things are working well, it pushes 
everything back in line. But if you have markets that are trading 
away from fair value for extended periods of time, that is a market 
malfunction, and for most people it is probably an opportunity for 
others. And that is an important way to think about it. 

Mr. King. And would you say that the more experience and his- 
tory we have with these market fluctuations, the fewer fluctuations 
we have, because you would have more traders that would identify 
it earlier, and those corrections would come into place naturally 
and more quickly? 

Mr. Gorelick. Absolutely. And one of the good things about the 
market changes that we have seen in this automated market is we 
are no longer just relying on several dozens of traders in a trading 
pit to be able to provide all that liquidity. We have the opportunity 
for people from all around the country and all around the world to 
look at this data on a level playing field, and try and push the mar- 
kets back in place. I think that has resulted in fairer markets with 
better pricing and more liquidity. 

Mr. King. All in real-time, which they don’t conceive of that in 
those Marxist countries. 

I turn to Mr. Vrabel, and would you agree there is natural mar- 
ket corrections? 
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Mr. Vrabel. I do, and I see it. Part of my team structure is to 
review market events. We have reviewed every event from the 
flash crash through the recent market turmoil with Brexit, and we 
see corrective activity from participants. An example is if we look 
at August 24 , 2015, when the Chinese equity market crashed, 
which led to a precipitous decline in our markets, we saw vastly 
different market activity than we did during the Brexit days. And 
a lot of this, I believe, based on having talked to firms, is that they 
learned from the market event of August 24, they learned from the 
Treasury flash crash of October 15 how to adjust to the market. 

Mr. King. And quickly, I ask you, do you believe that our traders 
are adequately collateralized? 

Mr. Vrabel. That the traders are adequately capitalized? 

Mr. King. Collateralized. 

Mr. Vrabel. Collateralized. 

Mr. King. Yes. Do they have their collateral underneath their 
trades adequately? 

Mr. Vrabel. Yes. And we have controls in place from our clear- 
inghouse structure, we have tools in place that allow firms to set 
capital limitations or risk limitations. So yes, I do believe so. 

Mr. King. Thank you very much. I thank all the witnesses. 

I yield back the balance of my time. 

The Chairman. The gentleman’s time has expired. 

Ms. Adams, 5 minutes. 

Ms. Adams. Thank you, Mr. Chairman, Ranking Member Peter- 
son. And thank you, gentlemen. 

High-frequency trading has certainly taken off quite a bit, and it 
is taking the trading industry by storm, with mixed results. While 
it is clear that the technology used in our financial markets is con- 
stantly evolving, we must be cautious and make sure that there are 
standards in place to regulate these new technologies. Obviously, 
Reg AT seeks to provide a regulatory regime for market partici- 
pants that engage in high-frequency trading, but what about the 
companies that only write trading algorithms and sell them to mar- 
ket participants? They are not market participants, but service pro- 
viders to market participants, and yet you can imagine that if one 
of the algorithms they provided is faulty in some way, this could 
cause or contribute to a market disruption. 

Mr. Ryan, what would be the best way to monitor or regulate 
third-parties who provide the technology, but do not trade? 

Mr. Ryan. Well, thank you for the question. Congresswoman. It 
is an interesting one. 

TT is generally not the type of entity that you are talking about. 
Although we offer some algorithmic trading tools, for the most part, 
we enable our customers to utilize their own algorithms onto our 
systems, or using our systems. 

Having said that, I believe that the answer to your question is 
that the algorithms that are provided by third parties can be tested 
by the traders and by the registered entities as products to see how 
they work in the market, and to see whether the intended effect 
actually happens. That is something that can be done today, and 
that is the appropriate way to test those types of tools. 

Mr. Wood. If I may just add to that. 

Ms. Adams. Yes. 
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Mr. Wood. The FMCs have a responsibility in providing access 
to the U.S. futures markets. We talk to customers who are using 
different types of software, and obviously, everyone has a responsi- 
bility to ensure what they are using to interact with the market is 
appropriate and has been tested. And obviously, a software pro- 
vider has a similar responsibility to ensure that their software has 
been adequately tested. However, when it comes to being used in 
the marketplace, it comes, again, back to these real-time param- 
eters that are used around the software. And we in the FCM com- 
munity will have many conversations with our clients about the 
types of software they use, the types of market access they want 
to use, and the types of risk controls that should be put in place 
appropriately. And to the previous question around 
collateralization of clients, the types of risk controls that we agree 
to put in place with our clients are based on a risk assessment of 
the client, and they will then act as a speed bump in situations 
where there may be overtrading. Now, overtrading may be delib- 
erate or it may be accidental through the way an algorithmic trad- 
ing system or automated trading system is using, but again, it 
comes back to the fact that we have to have risk controls in place 
to minimize any possibility that something may go wrong. 

Ms. Adams. Thank you. Several comments submitted during the 
comment period for Reg AT suggest that a lot of the definitions in- 
cluded in the proposed regulation are overly broad, particularly 
with regard to the definitions of an AT person, algorithmic trading, 
and floor trader. So what do you believe, and anybody can answer 
this, is the best way to set those definitions, and what are some 
of the challenges in drawing those lines, and should it be based on 
speed or on the way a market participant enters orders? 

Mr. Gorelick. There are a lot of concerns with the definitions 
that have been expressed and kicked around. One of the opportuni- 
ties that we have, if the goal is to improve market integrity and 
sort of relatively quickly, is to not worry about defining classes of 
participants with great detail because everyone will have different 
opinions on what the right definition is and who should be covered 
by what, but rather focus on making sure that there are risk con- 
trols on every order that goes into the market. 

So if we do that, we don’t need to focus on some of these bound- 
ary questions, and instead just worry about appropriate risk con- 
trols at every level of the process for all electronic orders. 

Mr. Wood. And if I can just add to that. One of the challenges 
with trying to create some sort of arbitrary boundary, as Richard 
said, and we have seen this in Europe as well where people have 
tried to create definitions of high-frequency trading, I was part of 
the CFTC Technology Advisory Committee, along with Richard, 
where we were trying to come up with a definition of high-fre- 
quency trading, and we decided we would not come up with a defi- 
nition because, first, it would be very broad, and it is a mechanism, 
not necessarily a style of trading, but also it creates a situation 
where you can almost arbitrage the situation by saying if I don’t 
meet the metrics that have been set as the boundary, therefore, I 
do not have to comply with this categorization. 

Ms. Adams. Thank you. I am out of time. Mr. Chairman, thank 
you, I yield back. 
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The Chairman. The gentlelady’s time has expired. 

Mr. Crawford, 5 minutes. 

Mr. Crawford. Thank you, Mr. Chairman. I thank the gentle- 
men for being here today. 

Mr. Gorelick, in 1992, Congress required the registration of floor 
traders to prevent felons from participating in the commodities 
markets. Today, the CFTC is attempting to use that same floor 
trader registration requirement to regulate the activities of propri- 
etary trading firms, most of whom would qualify as floor traders 
under Reg AT. Is there any harm in stretching the definition of 
floor trader to encompass those market participants? 

Mr. Gorelick. I am thinking about it from is there any benefit 
in doing that. I am sort of taking the flipside of that question be- 
cause I don’t think it is necessary to create a new registration cat- 
egory in order to accomplish the Commission’s risk management 
objectives. So I would start off by sort of questioning the benefit 
that is sought to be achieved with that new categorization. I would 
also say there are some obvious awkwardness around trying to 
shoehorn a group of market participants into an old definition. The 
old definition, for example, was geared towards individuals stand- 
ing on a trading floor, as opposed to a firm. 

Mr. Crawford. Yes. 

Mr. Gorelick. And there would be a lot of things that need to 
be smoothed out. What I have suggested is that it would make 
more sense to consider the registration requirements separately 
from the risk management components here, so that the Commis- 
sion could figure out what the right categorizations might be, who 
they are trying to capture. More importantly, what are the benefits 
that they seek to achieve through that registration. 

Mr. Crawford. What is your primary objection to the agency’s 
definition of direct electronic access? 

Mr. Gorelick. Yes, I have not questioned the details of the defi- 
nition as much as the need for that definition, again. If we are put- 
ting risk controls on all electronic orders, the question of exactly 
the mode in which someone connects to the market becomes irrele- 
vant and unimportant. We can just make sure then that we have 
the appropriate levels and layers of risk controls, regardless of the 
method of access. 

Mr. Crawford. And, Mr. Ryan, the same question to you. 

Mr. Ryan. Yes, I mean I agree with what Mr. Gorelick just indi- 
cated. However, I will also add that we have raised concerns be- 
cause we definitely have individual end-users who, for example, 
trade on their own account. And I actually had a conversation with 
a guy a couple of months ago about this. He told me about the way 
that he trades. He trades on his own account, he happens to share 
space with a bunch of other people who do the same thing. They 
share algorithms that they wrote in Excel, and they will use those 
algorithms throughout the day. They trade through an FCM whose 
infrastructure is hosted at one of TT’s facilities. The way that DEA 
is currently defined, that individual would have to register as a 
floor trader, arguably, because he is accessing the market through 
a system that isn’t physically hosted by the registered agent or the 
registered FCM. And so I think that is problematic. 
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Mr. Crawford. Okay. Mr. Gorelick, back to you. If an entity is 
required to be registered as a floor trader, what CFTC regulatory 
requirements would be imposed on them beyond those specified in 
Reg AT? 

Mr. Gorelick. Actually, I am not sure about that. I would be 
happy to look that up. I focus more on what are the requirements 
within Reg AT. 

Mr. Crawford. Yes. 

Mr. Gorelick. I am not familiar with the floor trader require- 
ments in any great detail. 

Mr. Crawford. Okay. Mr. Wood, do you have anything that you 
could add? 

Mr. Wood. With regards to the responsibilities of being a floor 
trader, I apologize, not really. The one thing I would say on DEA, 
what we have questioned, again, because it brings into scope a lot 
more participants than was originally intended in Reg AT, we have 
generally questioned its need because it becomes almost like an ar- 
bitrary trigger again in terms of creating a requirement around 
someone who has a particular type of market access, which then 
they don’t have to do if they then use a different type of market 
access by going through pipes provided by an FCM. And we think 
that it comes back to we should be looking more at what is the type 
of activity, as opposed to the mode of access to the market. 

Mr. Crawford. Okay. Mr. Ryan, did you have anything you 
want to add on that? 

Mr. Ryan. Well, I guess just to add to what I was saying before, 
the significance of having that individual that I was talking about 
trade through an FCM is that the FCM controls his risk already, 
and that is the key, it seems to me, not necessarily where the phys- 
ical trade is entered or how it is entered. 

Mr. Crawford. Okay. Mr. Vrabel, in the last 13 seconds, any 
comments? 

Mr. Vrabel. No, I can agree with what was said. The key issue 
for us is where the risk controls are being administered, either by 
the clearing member firm that has the ability to administer those 
controls, or if it is by the trading firm themselves that have created 
their own tools, and that is really where the line comes when look- 
ing at whether those controls are adequate and who is responsible 
for them. 

Mr. Crawford. Thank you. I yield back. 

The Chairman. The gentleman’s time has expired. 

Mr. Walz, 5 minutes. No questions? 

Austin Scott, 5 minutes. 

Mr. Austin Scott of Georgia. Thank you, Mr. Chairman. 

Mr. Gorelick and Mr. Wood, when Chairman Massad appeared 
before the Committee in February, I questioned him regarding the 
source code provisions in Reg AT, and his testimony was that the 
CFTC would only access source code using proper procedures. And 
why isn’t a subpoena the proper procedure to get highly sensitive 
information like source code? 

Mr. Wood. We would all argue that the subpoena is the appro- 
priate legal procedure for accessing intellectual property. As I said 
previously, it is an extreme situation though. There are other 



52 


methods to find out more information if there is a particular in- 
quiry without going to the subpoena level. 

Mr. Gorelick. I was reassured by Chairman Massad’s comments 
in that regard that they would be open to looking at what the ap- 
propriate safeguards are, and I would suggest that the subpoena 
process, as it has currently been in place, is probably the best place 
to start. 

Mr. Austin Scott of Georgia. Well, let me ask you this then, 
with the breaches and other things that we have had, and the gov- 
ernment pledge to look after your source codes, how much comfort 
does that give you that the government would be in possession of 
it and looking after it? 

Mr. Gorelick. The assurances, at the end of the day, would need 
to go beyond just merely we are going to take care of you, don’t 
worry about it. I think that there are lots of different types of safe- 
guards that can go in place around sensitive information, about 
who is able to look at the information and in what form they are 
able to access the information, what are the various levels of access 
printed copies versus connected to the Internet, et cetera, et cetera, 
that would need to be thought through and put in place to give 
comfort in that regard. 

Mr. Austin Scott of Georgia. Mr. Ryan, could you speak to the 
definition of source code and whether or not there is a universal 
definition, and specifically to Reg AT, if they have been clear about 
what the definition of source code is? 

Mr. Ryan. Sure. I mean as I indicated before, I don’t think that 
the general definition of source code is too controversial. Very gen- 
erally, as I said, it is a high-level software language that is in- 
tended to be intelligible to humans. 

Mr. Austin Scott of Georgia. Is it all written in the same com- 
puter language? 

Mr. Ryan. No. No. There are many, many different languages. In 
fact, TT uses in excess of 30 different languages. 

Mr. Austin Scott of Georgia. Is it easy to interpret? I would as- 
sume that it is not if you use that many different languages. 

Mr. Ryan. Absolutely. No, it is not. It is not. It is not even easy 
to interpret when you are talking to different software engineers 
who are working with the same sort of language. One software en- 
gineer’s source code might not be very obvious to another software 
engineer’s source code. In fact, that is typical. 

Mr. Austin Scott of Georgia. So then how would an agency 
maintain a staff that could actually use the information and derive 
anything that they may need out of the information? 

Mr. Ryan. I appreciate your question, and I think that would be 
very difficult for them to do. And again, I think that the partici- 
pants in the marketplace are willing and able to give as much use- 
ful information as we can, but there is definitely a question as to 
whether this sort of information is useful. 

Mr. Austin Scott of Georgia. Well, I don’t have any further 
questions, Mr. Chairman, most of the ones that I had have already 
been asked, but thank you for having this hearing. And, gentlemen, 
thank you for being here. 

And with that, I yield the remainder of my time. 
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The Chairman. The gentleman yields back. I also thank him for 
his chairmanship of the Subcommittee that has direct oversight on 
this. 

Mr. Thompson, 5 minutes. 

Mr. Thompson. Thank you, Mr. Chairman. Thanks to the mem- 
bers of the panel. 

Mr. Ryan, my first question is for you. Can you share some addi- 
tional detail about how commercial market participants utilize the 
tools that your platform provides? 

Mr. Ryan. Sure. We have many different trading tools that peo- 
ple can use, specifically with respect to algorithmic trading, to 
input their algorithms. For example, we have a tool called ADL, or 
Algo Design Lab, which enables an individual to basically drag and 
drop icons onto a user interface to create kind of a logic tree that 
ultimately creates an algorithmic trading strategy. 

We also have other tools that enable people to input algorithms 
or equations into the different cells on a user interface that, again, 
would enable them to use the algorithmic trading. It also inte- 
grates with things like Excel. Lots of our traders use Excel and in- 
tegrate it into our software, Microsoft Excel. And otherwise 
through APIs, they can integrate their algorithmic trading strate- 
gies through our software. 

Mr. Thompson. Sounds like many of your strategies and tools 
are pretty consumer-friendly in terms of, I don’t want to say algo- 
rithms for dummies, but maybe a kind of thing I could actually 
handle. I am not sure when you are talking about dropping icons. 

Mr. Ryan. ADL is one that we are particularly proud of, and the 
idea of it is that it enables regular traders, so to say, to be able 
to input algorithms without having to hire a software engineer to 
do it for them. 

Mr. Thompson. Yes. Market access. What would be the ramifica- 
tions for your clients if they were subject to the Reg AT simply be- 
cause they used your platform to execute their trades? 

Mr. Ryan. Well, I mean we have touched on some of the bigger 
concerns such as the source code repository. An example is that 
end-user that I was talking about before. When I was talking to 
him, he had told me that when he trades throughout the day, he 
will have a list of maybe ten different algorithms that he and his 
trading partners might use. They will be tweaking them through- 
out the day too, depending on market conditions. 

As written, that individual trader would have to keep track of all 
of those changes, all of the source code related to those changes, 
indicate how and when that was done, and have that available for 
review by the CFTC, again, without subpoena power, which is a 
tough task. 

Mr. Thompson. Well, thank you. 

For the rest of the panel, why would imposing risk controls on 
market participants, instead of registration requirements, be a bet- 
ter means by which to regulate automated trading? 

Mr. Vrabel. I will address it in part with some of my earlier 
comments that some of the disruptive activity we have seen in our 
markets have come from fairly simply automated strategies that 
would not necessarily be caught in how Reg AT is currently writ- 
ten. By participants that do not have direct electronic access, who 
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are nevertheless operating a simple automated strategy in the mar- 
kets. And they pose similar risks to the marketplace like some of 
the more sophisticated firms. 

Obviously, I think that everyone up here shares the same per- 
spective that we need to protect the entire market, not just a par- 
ticular subset of traders that would be burdened with these re- 
quirements. 

Mr. Wood. And if I may add to that. So when FCMs provide ac- 
cess to their customers, to the marketplace, we have discussions 
with the clients about what sort of systems they are using, what 
types of controls they have in place. And if they choose to bypass 
the systems that we provide for market access, where we have risk 
controls that we administer, and they choose to use either a third- 
party software which may or may not give the FCM the ability to 
set those risk controls, then if they are going direct to market with- 
out something the FCM can provide, then they have a responsi- 
bility to ensure that there are appropriate risk controls in place. 

The industry has generally taken that approach that there is this 
responsibility. The Commission feels that they have to go one step 
further with regards to then saying, “Okay, if you are not going 
through an existing registrant, you should become registered, and 
in this case it would be as a floor trader, because of the type of ac- 
cess you have.” 

We have generally argued within the industry that is probably 
going a little bit too far, though we have conceded that if someone 
chooses not to go through the risk controls provided by an existing 
registrant, such as an FCM, then, okay, they will become reg- 
istered in themselves. 

Mr. Thompson. Yes. Thank you, gentleman. 

Thank you, Mr. Chairman. 

The Chairman. The gentleman’s time has expired. 

Mr. Allen, 5 minutes. Rick. 

Mr. Allen. Yes, sir. Thank you, Mr. Chairman. And we have 
covered a lot of ground here this morning. Thank you so much for 
coming and at least educating me on this process. 

I just had a couple of general questions about the industry. Mr. 
Gorelick, you are in the business, and I just have a general ques- 
tion, what keeps you up at night? 

Mr. Gorelick. Well, there is a lot, obviously, we are in business, 
the competitive concerns are something that we spend a lot of time 
thinking about, making sure that we are keeping up with changes 
in the market, and competitive changes and competitive dynamics, 
and that is where I spend a lot of my time thinking. 

In terms of sort of risks to the market, I really worry about new 
regulation coming in, in ways that distorts how things are working 
pretty well right now. 

Mr. Allen. Yes. 

Mr. Gorelick. Things can always get better, and we should al- 
ways be working to improve. I don’t want to defend the status quo, 
however, some of the rules that are being proposed here and in 
other contexts definitely run the risk of unintended consequences 
that could make it a lot harder to manage risk, and that could take 
a lot of time and energy away from sort of our core functions of risk 
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management, and keeping up with competitive developments in the 
market. 

Mr. Allen. Yes. I am on another committee, Education and the 
Workforce. We have had a number of hearings on the fiduciary 
rule. Does that in any way affect your business, or are you familiar 
with that? 

Mr. Gorelick. I am not. 

Mr. Allen. You are not, okay. 

As far as your customer base, and again, this is just to satisfy 
my curiosity, your customer base, are they pretty much investors 
that know this industry, know this business, or are they folks that 
just kind of come and go in the market, and what incentives do 
people have to invest in these trades? 

Mr. Gorelick. Sure. So we are a proprietary trading firm. So we 
manage 

Mr. Allen. Okay. 

Mr. Gorelick. We trade our own capital. We put our own money 
at risk in all the trades that we conduct. So we don’t have direct 
customers in the traditional sense. 

Mr. Allen. I see. Okay. So from your standpoint then, as far as 
these regulations, if you are dealing with your own money what 
then would be the issues as far as the government is concerned? 

Mr. Gorelick. Well, as proprietary traders, we clearly have in- 
centives to make sure that we are managing our own risk. It is our 
own capital at risk, and so we are largely aligned with the goals 
of risk management throughout the market. 

Mr. Allen. I see. Okay. 

Mr. Gorelick. So I would think that that is the case. 

The interest of the government here is sort of protecting market 
integrity, and we very much share that concern. We want to make 
sure that we are participating in markets that are transparent, 
that are well-regulated, and that the public rightfully has con- 
fidence in. 

Mr. Allen. And that is one of the things that I have seen as far 
as my short time here, is that we have this tremendous disconnect 
between the regulatory part of this body versus actually the busi- 
ness community out there. And it sound like you all have put in 
a lot of your own regulatory environment to protect the industry, 
and I commend you on that. 

As far as what we can do as a Committee, and I will leave this, 
I have about a minute and a half left, what is the biggest thing 
we can do here as this body to protect the integrity of this industry, 
and certainly as far as our role in agriculture? 

Mr. Gorelick. The continued oversight responsibility of the 
Commission is very helpful. Holding hearings like this where you 
surface issues, and help to urge the Commission to continue to take 
into account the views of industry, and to identify where there are 
opportunities to improve the current regulatory framework. 

Mr. Allen. Mr. Wood, do you have any comment? 

Mr. Wood. I would absolutely echo what Mr. Gorelick said there. 
From the FCM perspective, obviously, we have put a lot of invest- 
ment into ensuring that we have the controls in place to obviously 
aid us in how we do our business in providing access to market 
participants, who are our customers. We would like to see a fair 
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and evenhanded continued regulation of the U.S. futures markets 
that is not too prescriptive or onerous or burdensome on the mar- 
ket participants. 

Mr. Allen. Yes. And I assume you will holler at us if it gets a 
little too restrictive? Good. 

Well, I am out of time. I will yield back. 

The Chairman. The gentleman’s time has expired. 

Mr. Benishek, 5 minutes. 

Mr. Benishek. Thank you, Mr. Chairman. Thanks, gentlemen. 

I missed your initial testimony, but I have a couple of questions, 
I am not as sophisticated as far as this market stuff as some of 
these people here. What are some of the disruptions to the market- 
place that, I think it was Mr. Vrabel described, like 20 or 30 inci- 
dents of market disruptions that have resulted from, I don’t know, 
programmatic trading policies, or something? Can you explain that 
to me a little bit more, what happened, and like pick a couple of 
examples, and then how did you fix it or what happened there, tell 
me about that? 

Mr. Vrabel. Sure. And just for clarity, the 15 to 30, or 15 to 20 
disruptions in the market based on my understanding of that 
study, it was not disruptions that were the result of algorithmic 
trading malfunctions, which is important to recognize. 

What we do though on a regular basis is monitor our markets 
for aberrations. And it could be as simple as we see a firm sending 
in a significant number of order messages over a given period of 
time, which may be indicative that their systems are malfunc- 
tioning. So this could have no impact on the marketplace at all, but 
we see conduct from that firm that seems like an aberration. And 
our ordinary course of practice is to reach out to that firm to try 
to identify the cause of that. And by and large, this causes the firm 
to say, “Yes, we realize the issue, we have implemented these new 
controls to prevent this from happening in the future.” That is how 
we monitor the markets and mitigate the potential of an algo- 
rithmic trading disruption. And that is really what is important 
that, in order to protect the market, you have to spend a lot of time 
working with the participants, rather than imposing very 

Mr. Benishek. Does this happen very fast though? I mean it 
seems to me that these kind of algorithmic trading — that stuff hap- 
pens really fast. I mean is there an opportunity to get in there and 
question them how this is working? 

Mr. Vrabel. It is. CME Group has a number of controls that are 
in place. One of them is a messaging throttle control. And what it 
does is, it imposes a threshold where if a firm breaches that 
threshold over a given period of time, we start to reject new orders 
that that firm is submitting. And if it gets egregious enough, we 
actually shut down their access to the exchange. So we have con- 
trols that can act much faster than I can look at my computer 
screen and see what is happening. 

Mr. Benishek. Right. Right. So how often does that happen? 

Mr. Vrabel. I don’t have numbers at-hand. I would say that it 
is not infrequent that firms have activity that causes us to prevent 
those orders. I would also say it is not always a malfunction. 

Mr. Benishek. Right. 
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Mr. Vrabel. Sometimes it could be intended activity based on 
the market moving. 

Mr. Benishek. Let me kind of go a different direction a little bit. 
Apparently, this Reg AT, if the participant violates an algorithmic 
trading policy, that is considered grounds for the CFTC to enforce, 
which seems kind of weird to me that your own rules, if you violate 
them. So what is to prevent you from writing very lax rules and 
then not reporting to the CFTC? I am just kind of curious about 
that. 

Mr. Gorelick. That is one of the concerns that we have raised 
with the CFTC, that it sort of provides a disincentive for people to 
have particularly restrictive internal policies and procedures, and 
that the incentive that would come from that would be to have the 
bare minimum that are required by law to make sure that you are 
not inadvertently bringing on additional liability to your firm. So 
that is one of the definitional issues that we have suggested need 
to be fixed. 

Mr. Benishek. All right. Thank you. 

Thanks, Mr. Chairman. I will yield back. 

The Chairman. The gentleman yields back. 

Mr. LaMalfa, 5 minutes. 

Mr. LaMalfa. Thank you again, Mr. Chairman. Please forgive 
me for having been in a different committee, if anything I ask may 
be a little redundant, having missed some of your previous testi- 
mony. 

But, coming back to the requirement that firms make their 
source codes available without a subpoena at CFTC is very con- 
cerning to everybody here today. It would seem to me that this 
change is really an important issue of privacy and protection of in- 
tellectual property. So do any of you on the panel have any addi- 
tional thoughts about how this agency could modify the code reposi- 
tory requirements in order to maintain that intellectual property? 
Anything you want to sum up with here? 

Mr. Gorelick. So one of the things that I suggested in my writ- 
ten testimony is that there is an opportunity for a sort of prin- 
ciples-based retention policy for source code that, working with the 
industry, could be defined in a way that is consistent with current 
practices, to ensure that when the CFTC needs access and gets a 
subpoena, and follows proper due process, that they can be com- 
fortable that the source code still exists within the firm in a rea- 
sonable way. 

Mr. LaMalfa. With a subpoena. 

Mr. Gorelick. With a subpoena, absolutely. 

Mr. LaMalfa. Which isn’t the pattern and doesn’t seem to be the 
policy coming forward? 

Mr. Gorelick. Correct. So this is a change that we are sug- 
gesting, an alternative that we are suggesting would be that a 
thoughtful principles-based retention policy should address the con- 
cern that the source code just doesn’t exist, but in order to access 
that, the CFTC would have to follow existing practices of using a 
subpoena and following the due process, and putting in place ap- 
propriate safeguards. 

Mr. LaMalfa. Gentlemen, do you wish to address that? Mr. 
Vrabel? Okay. All right, thank you. 
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The cost-benefit analysis, do you think there are really any bene- 
fits with the applications as to the end-users, the commercial end- 
users? Are they going to see anything they can put their finger on 
as a benefit? Gentlemen? Anybody? Don’t want to touch that one? 

Mr. Gorelick. Yes, I don’t think it will be very measurable. 

Mr. LaMalfa. Not very measurable, okay. Okay. 

There is a questionable interpretation of a long-time definition of 
floor trader that is my understanding. Do you think it takes into 
account the costs of floor registration with this new definition, and 
ongoing cost of compliance? 

Mr. Gorelick. I would say in general, if the rule were to be ap- 
proved in its current form, or close to it, it would impose significant 
costs on both the industry participants and on the Commission in 
trying to enforce it and keep up with it, and those need to be 
factored into account. Ultimately, those costs are not just borne by 
the professionals in the market, they do get passed onto the end- 
users in the form of 

Mr. LaMalfa. Certainly. Everything does. 

Mr. Gorelick. — higher transaction costs, less liquidity. I think 
that is something that we do need to be concerned about. 

Mr. LaMalfa. So you don’t think these costs are being taken into 
account by CFTC? This is being imposed. They are not really look- 
ing at that. 

Mr. Gorelick. It did not seem to me from the cost-benefit anal- 
ysis that they were looking at the broader impacts, that they were 
really looking at sort of more specific narrow cost concerns. 

Mr. Wood. I would echo that, yes, there is a wider concern that 
the cost-benefit analysis in the proposed rulemaking didn’t take 
into account what the potential impact on the marketplace would 
be from the burden of compliance with Reg AT. 

Mr. LaMalfa. It is kind of important to have that impact taken 
into account, isn’t it? Yes, okay. 

Thank you. I appreciate the panelists here today. Thank you, Mr. 
Chairman, for your graciousness. 

The Chairman. The gentleman yields back. 

Mr. Davis, 5 minutes. 

Mr. Davis. Thank you, Mr. Chairman. I appreciate all the panel- 
ists. 

Something like this seems that in this case we have market par- 
ticipants, and if you were given an opportunity to make comments, 
it seems like your comments weren’t heard before the rule was im- 
plemented, otherwise we wouldn’t be having this hearing today. So 
it is interesting, sitting on this side, to see that. And that is a con- 
cern to us. 

And I do want to start a question with Mr. Vrabel. And I want 
to know what will the CME do with all of the data that AT persons 
and ECMs are required to report under Reg AT? 

Mr. Vrabel. Under the requirements of Reg AT as it is currently 
drafted, not much. And here is the reason why. For example, the 
compliance reports that every AT person in a clearing firm would 
have to submit to the exchanges on an annual basis, the require- 
ments in the draft would only require us to review those every 4 
years. So we impose this burden on every firm to submit annual 
reports that the exchanges aren’t obligated to review. So it leaves 
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huge gaps where participants are submitting these reports, think- 
ing that the exchanges are endorsing them because they have sub- 
mitted them, when, in fact, they may have risk controls that are 
inadequate. 

Mr. Davis. Well, will this information help you reduce the risk 
of an algorithmic trading disruption? 

Mr. Vrabel. From our perspective, no. As has been discussed 
earlier, the algorithmic trading disruptions and the malfunctions 
that are caused from algorithmic trading, in order to ascertain the 
root cause of those requires highly complicated analysis; the type 
of analysis that won’t be gained from routine annual compliance re- 
ports that are submitted to the exchanges. 

Mr. Davis. And I apologize if you may have addressed this in 
your opening testimony, but were these concerns raised during the 
comment period? 

Mr. Vrabel. They were. 

Mr. Davis. And the result? 

Mr. Vrabel. There was no result. 

Mr. Davis. Yet. 

Mr. Vrabel. CME asked the Commission to extend the initial 
deadline so that we and others could come forward with more ro- 
bust proposals, and that request was declined. 

Mr. Davis. It was declined? 

Mr. Vrabel. It was declined. We are thankful that the Commis- 
sion reopened the comment period. Unfortunately, it was on a very 
small subset of the total proposed rule. 

Mr. Davis. Well, I would hope that they would take comments 
into consideration more seriously that we are hearing from many 
of you as the market users. 

Mr. Gorelick, or actually, the whole panel if you would like to an- 
swer this, do you believe that Reg AT’s cost-benefit analysis fully 
appreciates the ramification of Reg AT on market participants in 
terms of initial and ongoing cost of the compliance? Whoever wants 
to start. 

Mr. Wood. Generally as a panel, we feel that the cost-benefit 
analysis focused on certain aspects, but not on wider aspects. In 
terms of compliance with what is proposed in the full scope of Reg- 
ulation AT, it has a very large burden on pretty much all market 
participants, from those who would be classified as a floor trader, 
those who are already registered with the CFTC, perhaps as a com- 
modity trading advisor or commodity pool operator, who would find 
themselves in the category of an AT person. It imposes a burden 
on the FCMs in terms of what we have to do providing access to 
an AT person, and the reporting responsibilities, and it poses a 
burden on the DCMs, in terms of what they have to do in providing 
additional controls, and the reports that have to be filed with ev- 
eryone. That cost of compliance, unfortunately, will get passed on 
to the wider marketplace, so every type of market participant, 
whether they are commercial end-users, pension funds, asset man- 
agers, et cetera, in the that sense our main concern about Regula- 
tion AT is that this has a potentially large impact on how liquidity 
is provided in the U.S. futures markets that will ultimately be to 
the detriment of the end-user. 

Mr. Davis. All right, thank you. 
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Mr. Gorelick, I don’t have much time left so I want to ask you 
a specific question on this. Do you believe that the cost-henefit 
analysis fully appreciates the potential costs of an inadvertent re- 
lease of your intellectual property? 

Mr. Gorelick. No, that was not an area that was explored in the 
cost-henefit process, to my recollection. 

Mr. Davis. Okay. And any other comment you would like to 
make on this follow up. 

Mr. Gorelick. Sure. I would say one thing that often gets lost 
in these cost-henefit analyses is the competitive impacts of this reg- 
ulation. When you have burdensome regulations like this, the re- 
sult is the biggest firms can keep up with it, they can hire a few 
more compliance people, they can deal with the reporting require- 
ments, they can handle it, but it is the smallest firms that sort of 
drop out of the market because they can’t compete. And that has 
a negative impact in the competitiveness of the market in the 
short, medium, and long-terms. 

Mr. Davis. Thank you very much. 

My time has expired. 

The Chairman. The gentleman’s time has expired. 

Mr. Neugebauer, 5 minutes. 

Mr. Neugebauer. Thank you, Mr. Chairman. 

Mr. Gorelick, in your testimony, you stated that foreign govern- 
ments such as China are seeking to impose similar source code re- 
quirements on U.S. firms. Could you describe some of those efforts? 

Mr. Gorelick. Sure. I would actually refer the Committee to a 
comment letter that was put in by a variety of technology trade as- 
sociations and industry associations that deals extensively with the 
source code issue. They raise a number of actions in which the Chi- 
nese Government sought to impose a source code requirement on 
U.S. companies who were selling technology into China in certain 
sectors, and ultimately, they were persuaded that this was unprec- 
edented, not usual in the marketplace, and backed down from that 
requirement. The concern would be that this type of precedent that 
we would set would give excuses across the board in lots of dif- 
ferent industries to impose similar requirements, which would be 
very detrimental to American IP protection globally. 

Mr. Neugebauer. Yes, with a country we already have a prob- 
lem in that area, quite honestly. 

Mr. Gorelick, Mr. Vrabel, or Mr. Wood, what risk controls would 
Reg AT impose on market participants that are not currently being 
implemented? Are there new risk controls that will be required in 
implementing this? 

Mr. Wood. With the way Regulation AT is currently proposed, 
it comes across as a very prescriptive list of risk controls that an 
AT person and an FCM and a DCM should have in place. And sev- 
eral of those controls are already in use on a wide basis, but sev- 
eral of those controls are not. And as a more general concern, it is 
too prescriptive in how those controls should be applied in various 
places. And the view of the industry is generally the controls that 
are used should be appropriate to the type of activity, and to the 
market participant in terms of how they manage their risk, how 
the FCM manages the risk of providing access to the customers, 
and how the DCM manages the risk to how it protects the market- 
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place, as opposed to being as prescriptive in the way Reg AT is cur- 
rently proposed. 

Mr. Neugebauer. Yesterday, I chaired a committee a hearing on 
Fintech, and Fintech is a big world. And one of the things that 
keeps coming up is that people are coming up with innovative ways 
to make money and new business models, is that the regulatory 
community in many cases don’t understand the technology, and in 
many cases maybe don’t always understand the particular business 
model being imposed there. And so my concern is, and I wanted to 
hear your thoughts, my concern is, we see this innovation in the 
marketplace, and hopefully it makes markets more open, more effi- 
cient, and brings more liquidity to those markets. Do you sense 
that the regulatory community is kind of behind the curve and try- 
ing to play catchup, and trying to then fold some of this new tech- 
nology and these methods into old regulatory framework? 

Mr. Gorelick. I think that is a challenge in any regulatory envi- 
ronment, to keep up with technology, and I think that is something 
that we are seeing right here. And because there are new things 
going on in the market with new technologies that are constantly 
changing, we see the CFTC in one action try and catch up with 
every possible outcome of some of the changes that have occurred 
in the market in one rulemaking, and that is complicating the proc- 
ess a little bit. There is a consensus across the industry that the 
place to start is with risk controls, with pre-trade risk controls, and 
that there is an opportunity to really catch up a lot by focusing 
there, and then we can move elsewhere. 

I would say another area where the regulators can sort of im- 
prove their capabilities is their data analytics ability. When there 
are lots of people out there who look at market events and say, 
“Wow, this looks strange,” and they come up with their theories 
about what happened. The regulators are the expert agency who is 
well-placed to actually look at what occurred, and tell the public 
that this is what happened, and be reassuring where there is a 
need to be reassuring, and actually go and start enforcement or 
other compliance actions where there is a need to do that. Data 
analytics is another area that would help the Commission catch up 
very quickly. 

Mr. Wood. If I might just add there. We have seen the U.S. fu- 
tures markets evolve in the space of 15 years from being 100 per- 
cent floor-driven, to screen-driven, to now, as we were talking ear- 
lier about the high prevalence of some form of automated trading. 
We believe that regulations should be principle-based to allow for 
continued evolution, especially in markets that are very technology- 
driven, and obviously where innovation is constantly occurring. 
And to that point, what is proposed in Reg AT is too prescriptive 
and anchors you in a period of time that doesn’t necessarily allow 
for innovation and continued evolution. 

Mr. Neugebauer. I thank the Chairman. 

The Chairman. Thank you. The gentleman’s time has expired. 

I want to thank our witnesses. 

Let me follow up, Mr. Vrabel, you mentioned that the algorithmic 
trading users would, under your scheme, certify something, certify 
that they have tested. What were you asking to be certified, and 
who would set those standards, and would there be an outside, I 
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am a CPA by profession, and that word certify is a bit protected, 
but what would that look like, what would that certification look 
like? 

Mr. Vrabel. Sure. A certification could look like a firm, an auto- 
mated trading firm verifying that they are in compliance with a 
principle-based Reg AT regime. I can tell you that today, we re- 
quire firms to submit those types of certifications on their mainte- 
nance of Audit Trailer, their 5 year retention requirements. And I 
can tell you with 100 percent certainty that if a firm does not be- 
lieve it is in compliance, it will not certify that they complied with 
our rules. That causes us to then go interrogate the data and find 
out the reason why. And we have no reason to believe why that 
type of model that is currently enforced in FINRA, in a much more 
complicated securities world, wouldn’t work in our environment. 

The Chairman. All right. 

Well, I want to again thank you. I am hard-pressed to envision 
a circumstance where the CFTC could have on-staff a cadre of peo- 
ple who would pick out one of these firms at random, and go in and 
drag through their source code in enough detail to find that glitch 
that had been missed, and looking to prevent some disruption in 
the market. If I had a client who was cooking the books, I didn’t 
argue as to whether or not their automated general ledger system 
worked properly or not, I regulated what came out of it and go 
about that direction. So this whole issue around source code and 
those things, to me, seems to be wrong-headed, and I don’t know 
that it gets us much. 

On an after-the-fact, if someone has actually caused a disruption 
in the market, the violation is not going to be that they screwed 
up the code, the violation is going to be that they manipulated or 
hammered the market. And we don’t really care how it happened 
if we can prove what they did. And it is a real head-scratcher for 
me to understand the agency’s fixation on getting source code, hav- 
ing it in their own control, because I don’t know what they would 
do with it. They get a lot of data today that I don’t think they nec- 
essarily do everything that they should be doing with it, and this 
would just add more to that as well. 

I did not hear from any of you that you don’t want this arena 
regulated, that the conduct should just be free-flowing and laissez- 
faire, not one of you mentioned anything that remotely said this 
does not need to be regulated, but you did say that it ought to 
make sense and ought to be principles-based, as Mr. Wood just 
mentioned. And I am hopeful that this hearing and I see some rep- 
resentatives from the agency and others here, that the CFTC will 
respond to the comments made today, as well as the attention we 
have placed on this. But, the testing that I know Richard does on 
his team, as a market participant, if you had an algorithm you put 
in place and it did something you didn’t want it to do, and it didn’t 
disrupt the market but it caused you to be on the wrong side of 
all those trades, you have a vested interest, a proprietary interest, 
in not having a system that does something you don’t want it to 
do. And that is that first layer, and then all the various things we 
could put in place on top of that that gets to the system. And this 
proposed rule has a lot of fine-tuning that needs to be done. I was 
particularly disappointed to hear that the cost-benefit analysis was 
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not maybe as fulsome as it should have been. Chairman Massad 
and I have a running argument as to the way the CFTC does their 
cost-benefit analysis. I don’t believe CFTC takes into consideration 
the costs to market participants broadly, and I don’t think it takes 
into consideration the costs to the agency itself. If I want to build 
a fiefdom then I could build all kinds of regulatory schemes, it 
causes me to have to beef-up my staff, to put in place that cadre 
of 50 or 60 different expert software engineers to put on my team 
so that I can wade into your software. Well, that makes no sense 
if, at the end of the day, it doesn’t really prevent manipulation of 
the market. 

The other thing that earlier on was said somehow that this regu- 
latory scheme is going to be perfect, and that nobody will be able 
to violate it. Well, if that is the case, then perhaps the CFTC has 
discovered a technique that we could use perhaps in the real crimi- 
nal area, and maybe write rules that nobody gets murdered today, 
and all those kind of good things. There is a lot of work to be done 
in this. 

Again, thank you very much for you very clear testimony. It was 
great having you with us today. 

Under the rules of the Committee, the record of today’s hearing 
will remain open for 10 calendar days to receive additional mate- 
rial and supplementary written responses from the witnesses to 
any question posed by a Member. 

This hearing of the Committee on Agriculture is adjourned. 
Thank you. 

[Whereupon, at 11:54 a.m., the Committee was adjourned.] 

[Material submitted for inclusion in the record follows:] 
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Submitted Statement by Susan Beegles, Assistant General Counsel, 
American Gas Association 

The American Gas Association (“AGA”) ^ appreciates the opportunity to submit 
this statement for the record relating to the Commodity Future Trading Commis- 
sion’s (“CFTC”) proposed rule on Regulation Automated Trading (“Regulation AT”).^ 
AGA filed comments to the CFTC in this proceeding on March 16, 2016. 

The potential impact of proposed Regulation AT on AGA’s members is not insig- 
nificant. Absent an appropriately tailored and modified definition of “Algorithmic 
Trading,” AGA believes there would be a strong disincentive for AGA members and 
other commercial end-users to use Direct Electronic Access (“DEA”) for futures trad- 
ing activity on or subject to the rules of a Desimated Contract Market (“DCM”). 
AGA’s comments also expressed concern about the requirement that, for the first 
time, commercial end-users might be deemed “floor traders” and have to register 
with the CFTC based solely on the manner in which they trade — and the potential 
for Regulation AT, if applicable, to unwind or render inapplicable many of the provi- 
sions in other rules put in place to limit the burden and costs for commercial end- 
users, such as AGA members. 

As users of the futures markets, AGA members support and appreciate the 
CFTC’s efforts to bolster safeguards and risk controls in order to protect against the 
risk of malfunctioning algorithmic trading systems, and to increase transparency. 
However, AGA submits that it is vitally important that any new rules promulgated 
as part of Regulation AT preserve, and do not negatively impact, the ability of com- 
mercial end-users to access the futures markets and use futures as part of their risk 
management tools. Specifically, AGA is concerned that proposed Regulation AT 
sweeps too broadly in its reach, and as such, may: (1) have the unintended con- 
sequence of hindering the ability of commercial end-users to efficiently and cost-ef- 
fectively access the futures markets; and (2) create inconsistency and regulatory un- 
certainty regarding issues that commercial end-users and the CFTC just recently 
addressed in other rules, such as margin requirements for uncleared swaps (the 
“Margin Rules”), and record-keeping requirements.^ AGA believes that the CFTC 
need not, and should not, deem end-users to be floor traders solely because they uti- 
lize DEA for “Algorithmic Trading.” 

Simply put, AGA’s concern regards the impact of proposed Regulation AT on its 
commercial end-user members that may transact in futures contracts via DEA to 
a DCM for “Algorithmic Trading.” As proposed, the definitions, including “Algo- 
rithmic Trading,” “DEA,” and “floor trader,’’ are so broad and far reaching in scope 
that they may have the unintended consequence of actually discouraging companies 
looking to hedge their commercial risks from trading futures. In particular, commer- 
cial end-users could — with just one DEA futures transaction — fall within the defini- 
tion of a “floor trader” which requires registration with the CFTC, and concurrently 
fall within the definition of an “AT Person” subject to all the requirements of Regu- 
lation AT. 

Additionally, AGA is concerned that proposed Regulation AT potentially would 
impact the commercial end-user’s status under other rules that the CFTC has re- 
cently adopted or amended that address concerns raised by end-users. Becoming a 
“floor trader” by virtue of Regulation AT may inadvertently result in commercial 
end-users becoming “registered members” for purposes of the CFTC’s general record- 
keeping rules, specifically Rule 1.35(a). AGA submits that this would be an unfortu- 
nate step in the wrong direction, given this rule was recently amended to provide 
that commercial end-users as “Unregistered Members” do not have to retain pre- 
swap-trade communications or text messages or link all relevant data to a par- 
ticular swap. Additionally, AGA is concerned that because “floor traders” fall within 
the defined term “financial end-users” for purposes of the CFTC’s recently-adopted 


^The AGA, founded in 1918, represents more than 200 local energy companies that deliver 
clean natural gas throughout the United States. There are more than 72 million residential, 
commercial and industrial natural gas customers in the U.S., of which 95 percent — just under 
69 million customers — receive their gas from AGA members. For more information, please visit 
www.aga.org. AGA member companies provide natural gas service to consumers and businesses 
under rates, terms and conditions that are regulated at the local level by a state commission 
or other regulatory authority with jurisdiction. They use financial tools to hedge the commercial 
risks arising from the regulatory obligation to provide affordable, reliable natural gas service 
to customers — risks that include commodity price volatility. These tools may include futures con- 
tracts traded on CFTC-regulated exchanges, and over-the-counter energy derivatives. 

^Regulation Automated Trading, 80 Fed. Reg. 78824 (Dec. 17, 2015) (“Proposed Rule”). 

^See Margin Requirements for Uncleared Swaps for Swap Dealers and Major Swap Partici- 
pants, Final Rule and Interim Final Rule, 81 Fed. Reg. 636 (January 6, 2016), and Reeords 
of Commodity Interest and Related Cash or Forward Transactions, Final Rule, 80 Fed. Reg. 
80247 (December 24, 2015). 
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Margin Rules, commercial end-users that are “floor traders,” solely because of their 
automated trading in futures, would be subject to margin requirements in their 
swap trading. Thus, the potential impact on commercial end-users of the deflnitions 
in proposed Regulation AT would not be insigniflcant. 

Further, the proposed deflnition of DEA appears so broad as to include tools that 
DCMs are marketing, and make available for use by commercial end-users, includ- 
ing AGA members. The deflnition of DEA could be interpreted to include these com- 
mon order management tools even if they include DCM-administered risk controls 
and, notably, even if the market participant is accessing the DCM via a Futures 
Commission Merchant (“FCM”) with additional risk controls. As such, end-users 
may not be able to use these DCM-administered tools going forward — notwith- 
standing that the use of these tools may result in decreased fees — due to the high 
cost and burden that would be associated with the Regulation AT rules. AGA sub- 
mits this result is not in line with the CFTC’s commitment to minimizing the bur- 
dens and costs of its regulations on commercial end-users. 

AGA believes that subjecting all commercial end-users that use DEA to access the 
futures markets to the comprehensive and substantial requirements in proposed 
Regulation AT — including the requirement to register with the CFTC — would run 
counter to the CFTC’s laudable recent efforts to fine-tune its regulations to make 
sure that commercial businesses can continue to use the futures markets effectively. 
AGA appreciates that it has been a priority of the CFTC to make sure the overall 
regulatory scheme it puts in place recognizes the needs and concerns of commercial 
end-users, and that the overall framework is designed to minimize burdens on com- 
mercial end-users who depend on the markets to hedge normal business risks."^ 

The American Gas Association appreciates the House Agriculture Committee’s 
careful review of the CFTC’s proposed Regulation AT. The impact of this rule on 
end-users, notably gas utilities, may indeed be substantial, burdensome and costly. 
We look forward to working with the Committee, the CFTC and all other impacted 
parties to see that this matter is settled appropriately 
Respectfully Submitted, 

jj^ (5,|S^ 

Susan Bergles, 

Assistant General Counsel, 

American Gas Association. 
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'^opening Statement, Chairman Timothy G. Massad, Open Meeting on Proposed Rule on Mar- 
gin Requirements for Uncleared Swaps and Final Rule on Utility Special Entities (September 
17, 2014). 



